[pmwiki-users] conditional (:if enabled ...:)
jo at durchholz.org
Sat Apr 16 14:03:46 CDT 2005
> At 12:46 PM 4/16/2005, Joachim Durchholz wrote:
>> Radu wrote:
>>> Great solution. I doubt it depends on how many people like it, Hans.
>>> A typecast might even be cheaper than a conditional :)
>> Either way, the cost of execution is dwarfed by the cost of parsing the
>> PHP in the first place.
> I thought the zend engine does that last part pretty well. Which was one
> of the reasons why some time ago I started using php rather than perl.
Well, yes, but then you get the next thing that dwarfs execution times:
Apache, e.g. parsing the HTTP headers (or a gazillion of other things
that Apache does behind the scenes). Or setting up the environment
variables. (Did you ever run ?action=diag on a PmWiki? All these
variables have been set up, and many of them are never used.)
Even if these differences mattered, there's no way to predict which of
these variants is fastest. It may differ with PHP version or even
processor type (or even processor revision).
It's micro optimisation, and it's not even worth thinking about.
There are two things that can and should be done.
The first is algorithmic optimisation: use an O(N log N) algorithm
instead of an O(N^2) one. Lift computations out of loops (but do that
only if you *know* that the computations are expensive - more often than
not it's not worth the trouble). In scripting languages, make use of
builtin operations instead of rolling your own algorithms (this also
makes for shorter code, giving you less bugs to hunt).
The second is doing optimisation after the fact. Design your program
with reasonable flexibility in mind, but get it right first, *then*
optimise. Run a profiler and see where the program spends most of its
time, then optimise these parts. Even if you rewrite them from scratch,
it's still a win because you didn't have speed as a design constraint
for those 90% of the software that contributed to just 10% of the
running time (or memory usage). Just a few ballpark figures: assume that
10% of the code take 90% of the time (reasonable assumption), and that
you'd have to totally rip out those 10% and rewrite them for speed
(conservative assumption), you'll end up with a total effort of 130%
programmer time. Now incorporating efficiency into the design from the
ground up, this multiplies the effort for writing the software by 2 or 3
(let's assume 2). So writing for efficiency from the beginning gives you
a total time of 200%.
Doing optimisation as an afterthought can be risky. Sometimes you end up
with an unoptimisable structure. But given enough experience (and Pm
certainly has it, from what I have seen in his code), this risk is small
enough to be justifiable.
More information about the pmwiki-users