I remarked to someone who was bragging about how he'd managed to save 10 milliseconds off a function by using assembly language that you can't save milliseconds in a jar for later use. If all it does is get you back to the system idle state a tiny bit faster, it's probably not worth the effort.
Efficiency isn't everything, any more than the absolute lowest price is. When was the last time you said, "Yum, that meal tasted really efficient!"? Of course, if your systems are absolutely melting, that's another matter. I've spent years on that kind of stuff and for a small phenonmenal fee, I can help out. In fact, just to blow my own horn, this very morning I put in a solution that cut response time on some critical functions down from over 60 seconds/transaction to under 10. At which point, the bottleneck really was the user's web browser, not the app. But the boost you get by compiler settings or even in choice of programming language isn't where the major paybacks come from. The algorithm is what makes or breaks it at the code level, and the resource interactions can absolutely kill you at the higher levels. I worked in a major mainframe shop where the mainframe was going down like clockwork day after day. Mainframes aren't PCs. They're not supposed to go down. It's like having the entire LAN go down these days. You don't "CTRL-ALT-DEL" them, and if you re-IPL (mainframe-ese for reboot) at all, it's usually something like a scheduled maintenance on weekends. That's one reason WHY mainframes haven't gone extinct even yet. The solution wasn't clever code, it was changing one little configuration setting. On Fri, 2010-10-22 at 17:08 -0400, Andrew Henderson wrote: > On Fri, 22 Oct 2010, William L. Thomson Jr. wrote: > > > Is there ever a justification for slower, even if slightly? So its a few > > seconds slower. That adds up on ever run, and if doing several > > operations back to back. Those pennies of time add up :) > > Be careful. Those pennies come at the expense of dollars spent > developing, debugging, and maintaining. Being clever always has its > price. There are times when your hand is forced to develop for > performance, scalability, and/or minimal resource usage. Often though, it > comes down to deadlines, functionality, and maintainability instead. > > But if you can make something faster or more efficient and you can spare > the time, energy, and resources to make it happen, go for it! > > Andrew > > --------------------------------------------------------------------- > Archive http://marc.info/?l=jaxlug-list&r=1&w=2 > RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml > Unsubscribe [email protected] --------------------------------------------------------------------- Archive http://marc.info/?l=jaxlug-list&r=1&w=2 RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml Unsubscribe [email protected]
