I was trying to save one database trip for loading the User object (except the first time).
Why? Had you noticed a performance penalty with the extra database trip? Had your users complained? Were you 500'ing requests because your servers were overloaded?
If the answer to the above questions is no, then don't worry about performance. Performance is something that should be addressed if AND ONLY IF it becomes a problem.
</soapbox>
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
Was just looking through older threads (this one's not so old), and found this:
dragonchild: Performance is something that should be addressed if AND ONLY IF it becomes a problem.
Hm, if I'm contracted out to make a new application, why would I write it with any known future performance problems? The best way to fail to get a followup contract would be for a brand new application I wrote to start choking as more real users are allowed to touch it. I know there's such a thing as premature optimization, but I also know that there's a reason that DBAs get $120K to start... in Kansas.
"Halley, I know we said we expected Frobnitz.com to get a thousand hits a week, but Paris Hilton just mentioned how she loves her new Frobnitz in the middle of her latest inadvertent sex tape. The machine keeps falling over, and we're only getting a thousand hits an hour. Yet our popular Squonk.com site on an identical machine in the same rack is handling five thousand concurrent users easily. What the frell?"
--
[ e d @ h a l l e y . c c ]
| [reply] |
If you write for maintainability, then you will have written your code in such a way that optimization is very easy to do. That's because you wrote it in a decoupled fashion where it's easy to drop in a replacement section for a slow spot. For example, Class::DBI allows the coder the flexibility to change how a given class is working. Instead of doing discovery, you can have it use custom SQL.
After you have profiled why the machine is dying on 1000 hits/hour, you'll find that there are 2-3 specific places that the code is choking on. That means you only optimize 2-3 specific places. This is contrast to optimizing the whole damn application because you don't know where the slowdowns are going to be.
That results in a much lower overall cost to the owner of the application. What you haven't described is the differences between Frobnitz.com and Squonk.com. For example, what about
- The costs to get it written
- The speed at which it was written
- How many developers needed to maintain the code, both for bugfixes and enhancements
- How many bugs there are in the application, especially how many are user-facing
- The time it takes for a new developer to come up to speed
- What the damn thing is doing (does it depend on outside resources like a RDBMS?)
It may be that Frobnitz got up and running in 2 weeks with 2 developers as opposed to Squonk in 16 weeks with 5 developers (4 man-weeks vs. 80 man-weeks). Additionally, Frobintz only requires 2-3 hours/month in maintenance vs. Squonk who needs a full-time maintainer. That's because Frobnitz's bug-queue has never gotten beyond 2 bugs (total) and Squonk has 4 high-priority bugs in it at all times, two of which impact a large segment of the userbase. The complexity of the codebase means that it takes 2-3 months to get up to speed on Squonk, but we can have a random contractor come in for 2 weeks at a time and deal with the Frobnitz issues. Oh, yeah, and Frobnitz depends on a bunch of webservices (which aren't under our control) while Squonk is completely self-contained.
Admittedly, this is a somewhat contrived example, but you see where I'm going with this ...
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |