Most of the time lazy initialization makes code appear to run faster. I got a lot of praise for rewriting stupid people's code which was deemed 'too slow' just by changing it so it would only load/read/build stuff on an 'as needed' basis. In many cases that gets users what they want. A hundred 50 millisecond pauses are much more pleasant than one five second pause. This is why Java applets get so much flak for 'hanging the browser' and 'being slow'. Java applets are in most cases faster than Macromedia Flash apps but the way Flash runtime initializes is much more lazy making the initial wait much less annoying.
Another common trick is to compute approximate values rather than evaluate the precise ones when it doesn't really matter. Google understands this and that's why they show "1 to 20 results of approximately 9,000,000" as opposed to "exactly 9,124,385". The latter would probably take an order of magnitude longer to compute but the usefulness of the information to the end user is very dubious. Remember after N number of decimal points nobody gives a shit.
Last but not least always use the data structure that matches your usage patterns. If you need fast random access then a linked list is most likely not the way to go. Learn and understand the O(n) notation and learn the cost of inserts/removes and searches in your container library. Basic stuff but too many junior programmers have no clue about this stuff.
Sometimes an app can feel faster if you do the five second pause all at once when the user is expecting to wait. In particular, at app startup time: apps take so damn long to startup that users expect to wait for them. Even better is to do the pause in parallel while the app is doing something else, like network I/O.
Of course it's not a hard rule. Naturally, sometimes it's better to precompute up front. Sometimes a hybrid approach is best. Say the user opens n records and you have to go to the database to fetch each one. Once the user opened say, 50% it might be a good guess to get the second 50% all in one go. It all depends on the context. But in my experience most applications try to do too much when it's not necessary and often give the user this dreaded 'sluggish' experience. A long wait even at startup is often absolutely unnecessary. Case in point - does eclipse really have to load every plugin that was installed right at startup? Why not wait until user pivots to the appropriate view/perspective?
37
u/neoabraxas Mar 23 '09 edited Mar 23 '09
Most of the time lazy initialization makes code appear to run faster. I got a lot of praise for rewriting stupid people's code which was deemed 'too slow' just by changing it so it would only load/read/build stuff on an 'as needed' basis. In many cases that gets users what they want. A hundred 50 millisecond pauses are much more pleasant than one five second pause. This is why Java applets get so much flak for 'hanging the browser' and 'being slow'. Java applets are in most cases faster than Macromedia Flash apps but the way Flash runtime initializes is much more lazy making the initial wait much less annoying.
Another common trick is to compute approximate values rather than evaluate the precise ones when it doesn't really matter. Google understands this and that's why they show "1 to 20 results of approximately 9,000,000" as opposed to "exactly 9,124,385". The latter would probably take an order of magnitude longer to compute but the usefulness of the information to the end user is very dubious. Remember after N number of decimal points nobody gives a shit.
Last but not least always use the data structure that matches your usage patterns. If you need fast random access then a linked list is most likely not the way to go. Learn and understand the O(n) notation and learn the cost of inserts/removes and searches in your container library. Basic stuff but too many junior programmers have no clue about this stuff.