The Three Byte Fix
breckyunits.com
breckyunits.com
The latter is exactly what I would have done. If the algorithm did not match the expected complexity, the most likely reason is a bug in the implementation, and the quickest way to find that bug is to compare it with a known-good implementation, such as the one that the code was ported from.
I didn't read through the code but maybe the library was small and this was just a case of checking the difference between c++ and js by line for 1k lines or something
In this case, if you can see two code based behaviors have diverged, just run both through a step by step debugger and see where they diverge.
Or if you run both through a profiler, you can see what segment of code is taking a crazy amount of time in comparison.
In general, narrowing down what you’re looking at is the goal. In this case, a big hint is that the code should be O(nlogn) but is actually O(n^2) which is a huge hint that we’re in a nested loop and the break condition isn’t getting triggered properly. I would have looked closely at the loops because of this.
The code itself is ~400 lines long minus a bunch of comments. This feels very approachable to skim through in an hour.
I also love creating new variables and naming them what I’m learning. Often times naming things will make bugs very obvious.
Agreed. There should be a formalish name for this technique/style.