[nycphp-talk] Per-/con-ceptual problems with object orientation code loading
nyphp at websapp.com
Tue Jun 18 17:32:37 EDT 2002
Here: buy some time...
From: charles at softwareprototypes.com
[mailto:charles at softwareprototypes.com]
Sent: Tuesday, June 18, 2002 5:18 PM
To: NYPHP Talk
Subject: Re: [nycphp-talk] Per-/con-ceptual problems with object
orientation code loading
YOU DON'T EVEN UNDERSTAND THE PROBLEM!!!! I'D FIRE YOU ON THE SPOT!
IF MY CODE LOADS ONE FRIGGIN' BYTE THAT ISN'T NEEDED, IT WASTES A
BYTE IN RAM AND THE TIME IT TOOK TO LOAD IT. DO YOU UNDERSTRAND THAT?
OF THOSE, THE TIME IS THE MOST PRECIOUS.
When you can point me to a store that sells time, then you can start
telling me I'm SCREAMING at you because I'm HYSTERICAL.
The Zend accelerator is NOT magic. It doesn't use persistence so you
still incurr that first hit and if you swap out or otherwise run out
of RAM, you incurr that first hit again and again and again.
If you REALLY run out of RAM and swap space due to memory contention
because you've got too many pages being hit too many times, you are
SO SCREWED! You have just set your system up to fail at precisely the
WORST possible time.
Load-units are only a nightmare if your code is not organized. They
are NOT the concern of the coder/developper.
If the code IS organized, then the optimizations occur BELOW the
packaging and the coder/developper doesn't even know about it.
Nobody will know exactly what's used most until its actually deployed
and its possible to gather up some usage stats. Then you gather up
code unto load-units. That's NOT the codes worry.
The system tuner can optimize load-units according to what's really
encountered and the developper just codes one method at a time and
doesn't have to worry about tuning in the larger view. There may be
inter-application contentions that he can't do anything about.
Abstracting doesn't work if theres ONLY ONE CLASS. Subclassing
doesn't help in those conditions either. The Object class will have
thousands of methods if you can't trim it to only what the
Concern yourself with writing optinal code because the crap you spew
will return to haunt you on the unemployment line.
Make every code path as clean as you can and never waste the user's
time. Your code will run X millions of time. Take a minute more to
write something which will run z% faster because, z% multiplied by X
million times a month can make the difference between needing another
expensive server, which will not make your employer happy, or worse,
having a site that's unusable, that users will bitch about and not
come back to.
More information about the talk