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 :-)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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/)