Hyperoptimizing for the fast path today and ignoring that hardware and usage patterns change is the reason modern software is so slooow :)

A more robust strategy would be at least be to check if the rule was the same as the previous one (or a small hash table) so that the system is self-healing.

Ken’s solution is at least robust and by that property I would prefer it since it’s just as fast but doesn’t have any weird tail latencies where the requests out of your cache distribution are as fast as the ones in.

▲

Jean-Papoulos 4 days ago | parent | next [-]

You were shown an example of exactly why this thinking is incorrect but you still insist...

Also, it's trivial to keep Ken's implementation as the slow path. If request patterns change, dig up the new fast path and put the old one in Ken's slow path code. Most of the performance will still come from the initial `if`.

	▲	vlovich123 4 days ago \| parent [-]
		It’s ungenerous to assume I would be against the if statement + Ken’s. But Ken’s approach is critically important and the “if” statement should just be a 1 entry cache instead of being hard coded. Getting this stuff right in a future proofed durable way is actually quite hard even when you notice the opportunity.

▲

necovek 5 days ago | parent | prev [-]

Nobody is hyperoptimizing the fast path today.

Ken's solution was stated to have been slower than the alternative optimization.

	▲	akie 5 days ago \| parent [-]
		Ken's solution optimized the general case, basically everything that doesn't match the if-statement.