8 ms·
This is fine assuming the popular request types don’t change, but arguably if both new versions of matching are sufficiently fast then I would prefer Ken’s long
by ralegh 1y ago
This is fine assuming the popular request types don’t change, but arguably if both new versions of matching are sufficiently fast then I would prefer Ken’s long term as the other could become slow again if the distribution of request types changes.
- sfilmeyer 1y agoAs a counterpoint, what fraction of the future engineers who will touch the project are likely to be able to competently edit the finite automata based version without introducing bugs and what fraction will be able to competently edit the if statement that checks the particular policy?
- mikepurvis 1y agoA further question mark is whether any of this has sufficient instrumentation to be able to notice and act on a change of and when it occurs.
- andrepd 1y agoNonsense. The pre-check can literally be one line (if common_case {fast_path()} else {slow_path()}), and thus enabling or disabling it is dead simple and obvious if the problem changes in the future. Lines of thinking like that are part of the reason most modern software is so sloooow :)
- ants_everywhere 1y agoYou can even track the request statistics live and disable the fast path if the distribution of requests changes significantly.
- Rendello 1y agoThis situation where two paths produce the same output but one is optimized is the easiest case in property-based testing, as the property is just: normal(x) == optimized(x)
- Stratoscope 1y agoI have sometimes done just this. First I write the simplest possible brute force code, something that any competent programmer can look at and say, "Yes, this may be slow, but it is straightforward and obvious that it will handle all cases." Then I write the optimized code and use a test like yours to compare the results between the simple code and the optimized code. One time I needed to write a function to search for a specific pattern in a binary file and change it. So I wrote the brute force code as a first step, the same code that anyone would probably write as a simple solution. It worked the first time, and a couple of people reviewed the code and said "yep, even if it's slow, it is correct." But this code took more than a second to run! Of course I thought about optimizing it with Boyer-Moore or the like. Then I went, "Hold on to your horses. This isn't something like a web page load where one second matters. It's part of a build process that only runs a few times a day and already takes several minutes to run. One extra second is nothing!" In the wise words of Kenny Rogers in The Gambler: You got to know when to hold 'em, know when to fold 'em Know when to walk away and know when to run
- throwaway-kg8d5 1y agoVery true. I would have gone with Every coder knows the secret to optimizin’ is knowing what to throw away and knowing what to keep
- deleted 1y ago[deleted]
- scott_w 1y agoAlso true for deciding whether to write code at all! About 15 years ago I was working with a junior who'd spent 3 hours trying to automate some data editing until I said "mate, you can just edit it all by hand in about an hour!"
- VBprogrammer 1y agoFunny enough, with LLMs this trade off may well have flipped. For simple tasks like given a string like X, format it like Y, they work amazingly well.
- vlovich123 1y agoHyperoptimizing 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.
- necovek 1y agoNobody is hyperoptimizing the fast path today. Ken's solution was stated to have been slower than the alternative optimization.
- akie 1y agoKen's solution optimized the general case, basically everything that doesn't match the if-statement.
- Jean-Papoulos 1y agoYou 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 1y agoIt’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.
- scott_w 1y agoI think you missed the point. Ken's version wasn't removed, it was simply prepended with something like: if value in most_common_range: take_fast_path() else: use_kens_solution()