[development] coding standard question
jeff at viapositiva.net
Tue Aug 28 00:16:37 UTC 2007
> Sorry to add more salt to the open wound, but i am with Steve Rude on
> this one. when it comes to drupal, we should hang onto every
> improve performance. even small things like changing upper case TRUE
> to lowercase. as some have mentioned: in a single request drupal
> not have enough such cases to make a difference. but when your site
> receives a lot of traffic, something as small as this might make a
Even if the capitalization parsing did trigger a speed hit, the
'worst case scenario' posted earlier in the thread still reveals a
small enough difference that it vanishes into the realm of
statistical noise. The execution time of a raw chunk of PHP is not
where Drupal's problems lie, plain and simple. The problems lie in
the memory and database footprint.
As an experiment, look at the timing differences, then look at how
much time it takes to execute a single SQL query. Think hard on that
for a moment. By eliminating a *single SQL query* from your page
load, you will save more time than can be saved by all the constant-
capitalization-tweaking in the world.
Hyper-optimizing for questionable gains due to undocumented
idiosyncrasies of a particular language's parser -- especially when
there are other well-known speed issues -- is a bad idea. You saw
this in eons past with C and other languages, where the 'speed gains'
of a switch statement over an if/then/else statement were cited.
Those gains vanished as compilers got better, and any gains we'd
receive from this capitalization change (if any) would be wiped out
by the use of an opcode cache, something that's all but required for
any site getting enough traffic to worry about these kinds of
Drupal's existing coding standards are geared towards readability and
consistency, and the use of TRUE, FALSE, and NULL as capitalized
strings is good. I vote for changing coder.module to mirror the
defined coding standards.
More information about the development