On Sat, 26 Jan 2002, Stas Bekman wrote: [...] > > It's much better to build your system, profile it, and fix the bottlenecks. > > The most effective changes are almost never simple coding changes like the > > one you showed, but rather large things like using qmail-inject instead of > > SMTP, caching a slow database query or method call, or changing your > > architecture to reduce the number of network accesses or inter-process > > communications. > > It all depends on what kind of application do you have. If you code is > CPU-bound these seemingly insignificant optimizations can have a very > significant influence on the overall service performance. Of course if > you app, is IO-bound or depends with some external component, than your > argumentation applies.
Eh, any real system will be a combination. Sure; when everything works then it's worth finding the CPU intensive places and fix them up, but for the most part the system design is far far more important than any "code optimiziation" you can ever do. My usual rhetorics: Your average code optimization will gain you at most a few percent performance gain. A better design can often make things 10 times faster and use only a fraction of your memory. > On the other hand how often do you get a chance to profile your code and > see how to improve its speed in the real world. Managers never plan > for debugging period, not talking about optimizations periods. And while > premature optimizations are usually evil, as they will bait you later, > knowing the differences between coding styles does help in a long run > and I don't consider these as premature optimizations. If you don't waste time profiling every little snippet of code you might have more time to fix the real bottlenecks in the end. ;-) [...] > All I want to say is that there is no one-fits-all solution in Perl, > because of TIMTOWTDI, so you can learn a lot from running benchmarks and > picking your favorite coding style and change it as the language > evolves. But you shouldn't blindly apply the outcomes of the benchmarks > without running your own benchmarks. Amen. (And don't get me wrong; I think a repository of information about the nitty gritty optimization things would be great - I just find it to be bad advice to not tell people to do the proper design first). - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
