Re: Does anyone have a list of 'donts' when optimizing?
by talexb (Chancellor) on Apr 16, 2002 at 14:10 UTC
|
Don't work on speeding stuff up that has little or no effect on the overall efficiency.
Reminds me of the time I helped my friend move a clothes washer. I insisted that we remove the agitator first, and spent five minutes removing it to find -- surprise! it only weighed about a pound, and we still had to carry the rest of this 180 pound monster up a flight of stairs and onto a pickup.
He was very patient. Never said a thing, but he sure smiled a bit.
--t. alex
"Nyahhh (munch, munch) What's up, Doc?" --Bugs Bunny
| [reply] |
|
| [reply] |
Re: Does anyone have a list of 'donts' when optimizing?
by thelenm (Vicar) on Apr 16, 2002 at 15:39 UTC
|
My favorite quote about optimization:
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
- M.A. Jackson
And some others I blatantly stole from the Java Optimization page:
"More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including blind stupidity."
- W.A. Wulf
"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil."
- Donald Knuth
"The best is the enemy of the good."
- Voltaire
| [reply] |
Re: Does anyone have a list of 'donts' when optimizing?
by Fletch (Bishop) on Apr 16, 2002 at 14:53 UTC
|
If you can at all manage it, don't run as a CGI. Use
FastCGI or mod_perl. That'll immediately cut the overhead
of each request by a large amount. And see the excelent
mod_perl guide
for mod_perl specific tips.
If you must have real CGIs, fork off a child (or pass
off the work to another persistent process) to finish
any long running tasks after you've interacted with the
browser. That'll let the httpd you're interacting with
go on and service another request.
| [reply] |
Re: Does anyone have a list of 'donts' when optimizing?
by wardk (Deacon) on Apr 16, 2002 at 14:18 UTC
|
one "DO" comes immediately to mind as I have dealt with it recently with
a system that went from reasonably few transactions (departmental) to high volume (enterprise wide usage).
If using a database, create as few connections as possible.
DB connections are expensive and in a high transaction CGI (as well as non-CGI) scenario,
creating multiple connections where less (one is best) will do will have a significant
impact on your response time, as well as anyone else you may be sharing
db resources with (like listeners).
Of course this suggestion (as well as many
others you may receive on this) is really valid for all languages.
| [reply] |
Re: Does anyone have a list of 'donts' when optimizing?
by dws (Chancellor) on Apr 16, 2002 at 15:47 UTC
|
Mostly im asking if anyone has something like 'Top 5 functions to avoid when trying to write speedy code'
Avoid
sleep()
Seriously, though, my answer is:
"Don't worry about speed before it's clear that a) speed is important, and b) speed is a problem, and c) the problem is
one you can get at."
I've seen too much time go down the drain in projects when somebody decides to rework some chunk of the system to be as fast as possible, when it really didn't matter. The result is usually code that's problematic (less readable, less supportable) than if they'd just been straightforward.
Performance problems are almost always algorithmic (where "algorithm" includes the structure of SQL queries).
| [reply] [d/l] |
Re: Does anyone have a list of 'donts' when optimizing?
by tachyon (Chancellor) on Apr 16, 2002 at 18:54 UTC
|
To optimise you need to identify where the time is spent. The most useful tool is Devel::DProf which will detail the percentage of time spent in each section of your code. You are wasting your time doubling the speed of a part of code that only takes up 1% of the total runtime. On the other hand a small improvement in bottleneck areas will reap large benefits. Assuming you have a 'normal' database driven website consider:
- Profiling with tools, see Devel::Dprof is your friend
- Optimising bottlenecks with Benchmark et al
- use mod_perl and Apache::Registry or for vanilla CGI CGI::Simple or CGI.pm in order of speed to process your params.
- Generate a cache of static documents for slow changing content rather than serving all requests from a database
- Connect to your database once (slow) and use prepare_cached($sql) with ? placeholders in the SQL and then execute(@values)
- Think about how much your time is worth versus the cost of new faster equipment or more ram or more processors or faster disks or a better load balancer or....
Often perlcode per say is not the bottleneck. You can't effectively optimise unless you identify where it is worth investing the effort.
cheers
tachyon
s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print
| [reply] |
Re: Does anyone have a list of 'donts' when optimizing?
by Biker (Priest) on Apr 16, 2002 at 14:03 UTC
|
while(1){}
Everything went worng, just as foreseen.
| [reply] [d/l] |
|
Not really hints on how to optimise, more hints on how to avoid a lot of problems with it. Make sure your code works beforehand, and use unit tests such as Test::More, or Test::Harness to make sure your code remains working whilst you're torturing it. Yes, there are rather a lot more of them to chose from if you look.. this is one wheel important enough that it's worth having a few choices as to what colour you want.
Oh, and make sure you know the output from your profiler. There's nothing worse than optimising the wrong part.
<CITE>"Premature optimization is the root of all evil."
- Donald Knuth</CITE>
| [reply] |
Re: Does anyone have a list of 'donts' when optimizing?
by simon.proctor (Vicar) on Apr 16, 2002 at 15:23 UTC
|
Don't think theres always another optimisation you can apply.
You'll end up wasting time shaving that extra microsecond off when you could be focusing on a better solution, an n-tier application for example.
Update: fixed my bad English :). Guess I'm too tired. | [reply] |
Re: Does anyone have a list of 'donts' when optimizing?
by danichka (Hermit) on Apr 16, 2002 at 19:38 UTC
|
Optimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught.
--Larry Wall
My list of don'ts is pretty short. Don't get caught! :)
use Your::Head;
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in. |