I'd imagine it's pretty rare that you can get an orders-of-magnitude speedup without it indicating a severe lack of something or other on the part of the original developer. (Be it understanding, or time and effort, or business case, or something else.) About the only exceptions I can think of would be if an external constraint of some sort disappears (patent expiry, perhaps?), or if algorithms research comes up with a previously completely unknown better approach to the problem.
I rewrote my bosses code one time (she wasn't a full on developer, more an ideas-gal), which implemented a huge speedup, possible > x20. We were doing a exam system that would pull in results for a 5 year course. She had lot of loops calling SQL queries, I replaces it with one big SQL query, that pulled in all the data, and then looped through the results, displaying them correctly. This stopped the page from timing out, which made everyone happy.
Only problem was, when I left someone else had to take over that project, and they didn't understand what I had done either. The original way was the easiest to understand, my way was very messy but fast. I recommended that they look at the original code.
Hah! Just five minutes ago, I was reviewing a patch on our internal code that produced a 200x speedup on a bit of code.
There, the change was from "hadn't gotten around to implementing a parallel version of this particular function that uses the hardware accelerators" to "had". (In this case, that would be the SPEs on the Cell/B.E. processor. But any hardware with SIMD and lots of multicore would likely get at least order-of-magnitude speedup of similar functions from the simplistic C code version to a version that used all the hardware.)
Actually, I keep doing this to myself ... mostly by replacing O(N^2) with O(NlogN) as N inevitably grows ... I generally do it the most obvious and easy to debug way, then consult the profiler to decide if it is worth doing the fancy way.
An example would be a toy event-driven simulator which I wrote the first time using an linked list as the priority queue. For small N, the priority queue barely registered. As the size and complexity of the networks I'm interested in increased, that rose to 90% of the CPU time! Replacing that with a heapq took very little effort and dropped the queue overhead down to 10% or so. If N keeps growing, I'll probably have to come up with something cleverer eventually ... but to do it now would be a waste of time, it might never happen.
Or, to put it in terms of Wall's Virtues, I like to wait until Impatience outweighs Laziness. After all, to do it _before_ it becomes annoying would be Premature Optimization :-)
Another way it could happen without reflecting too badly on the original developer would be finding a way to trick a SQL optimizer out of doing something stupid.
Oracle seems to be a lot more prone to that than SQL Server. One big area is that the optimizer forgets everything it should know if there's a user-defined function call in a Where clause. Oracle will try to run that before the rest of the conditions, and it will not notice if none of the parameters to the function are coming from the query. I got a ~200x speedup in PL/SQL code written by a friend of mine by putting the results of a function call into a variable before running the query.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Only problem was, when I left someone else had to take over that project, and they didn't understand what I had done either. The original way was the easiest to understand, my way was very messy but fast. I recommended that they look at the original code.
There, the change was from "hadn't gotten around to implementing a parallel version of this particular function that uses the hardware accelerators" to "had". (In this case, that would be the SPEs on the Cell/B.E. processor. But any hardware with SIMD and lots of multicore would likely get at least order-of-magnitude speedup of similar functions from the simplistic C code version to a version that used all the hardware.)
Two-orders-of-magnitude speedups don't necessarily require the original coder to have been particularly foolish, and are surprisingly easy to come by.
An example would be a toy event-driven simulator which I wrote the first time using an linked list as the priority queue. For small N, the priority queue barely registered. As the size and complexity of the networks I'm interested in increased, that rose to 90% of the CPU time! Replacing that with a heapq took very little effort and dropped the queue overhead down to 10% or so. If N keeps growing, I'll probably have to come up with something cleverer eventually ... but to do it now would be a waste of time, it might never happen.
Or, to put it in terms of Wall's Virtues, I like to wait until Impatience outweighs Laziness. After all, to do it _before_ it becomes annoying would be Premature Optimization :-)
-----sharks (http://nick.zoic.org/)
Oracle seems to be a lot more prone to that than SQL Server. One big area is that the optimizer forgets everything it should know if there's a user-defined function call in a Where clause. Oracle will try to run that before the rest of the conditions, and it will not notice if none of the parameters to the function are coming from the query. I got a ~200x speedup in PL/SQL code written by a friend of mine by putting the results of a function call into a variable before running the query.