[gregod]

I think the following minor optimizations can further decrease the runtime:

* There is no use in first pop()ing a candidate from the "reacts" list and then potentially re-pushing them later. Getting a pointer to the last element, and removing it if it is not needed, is more efficient.

* Reordering the character equality condition could help a tiny bit since the inequality check should be faster than the ignore case check.

[creata]

> Reordering the character equality condition could help a tiny bit since the inequality check should be faster than the ignore case check.

I think the given ordering is better: in a conjuction, you typically put the less likely condition first, not the cheaper one.

[gregod]

Good point. Here it is premature optimization anyway and too dependent on the input. In general, I think a balance between likelihood and cost should be found.

Out of curiosity, I just did a small benchmark (criterion) using the input.txt provided, and reordering results in a 10% difference:

  Old Order time:[307.28 us 309.12 us 311.17 us]
  Reversed  time:[270.82 us 271.18 us 271.54 us]

This feels weird since the input.txt contains few pairs of equal characters, so there is likely something else going on. The inequality is very inexpensive but the ignore case compare should not be that expensive either.

[rossmohax]

What if you add PGO to the mix, how fast it is going to be?

[gregod]

Weirdly enough, PGO equalizes and increases the runtime, where both methods take approximately 330 us. (I simply applied PGO to the full benchmark harness, no idea if this is proper). Them being equal sounds more reasonable, but the increase in runtime doesn't feel right.

Micro benchmarking remains a fickle beast :)

[renox]

I remember the talk where two different users measured different performance due to the username length..