Perrin Harkins wrote: >>The point is that I want to develop a coding style which tries hard to >>do early premature optimizations. >> > > We've talked about this kind of thing before. My opinion is still the same > as it was: low-level speed optimization before you have a working system is > a waste of your time. > > 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. 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. Definitely this discussion has no end. Everybody is right in their particular project, since there are no two projects which are the same. 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. _____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
