[wp-hackers] This is a Performance Enhancement? Clarification

[Jacob Santos]

scribu,

Well, yeah. You are correct. I just get tired arguing with people who 
have no idea what they are talking about and since not enough people 
read Trac, it wouldn't have mattered replying anything of substance 
there. Likewise, not enough people read my blog, so to get people to 
stop thinking incorrectly, I decided to first comment sarcastically to 
what you commented on without actually naming anyone and then ask that 
someone explain why they believe that something that you could use 
common sense to figure out isn't more widely accepted.

I think part of the problem is one of respect and not enough of 
research. I remember in the past two instances where I had to battle 
tooth and nail to get people to understand the fallacy of what they were 
writing.

Myth 1. Inline documentation slows down PHP.

The fact is that it is impossible to accurately tell how much overhead 
it causes, because comments are stripped out during the parse phase, so 
by the time execution is started, there is no way to tell how much time 
was spent stripping out the comments. All anyone can say for sure is 
that there is overhead in the parsing [1], but how much time is minute 
since parsing has a lot of rules for skipping over many comments very 
quickly.

This myth had to be overcome before much of the inline documentation 
effort could be made. An example of the advantage outweighs any minute 
overhead [2].

Myth 2. Conditional loading speeds up PHP.

The problem I have with the comment [3] is that it uses the myth that 
conditional functions and file loading speeds up execution of PHP, when 
you can not find a single source that will ever say this. In fact, all 
of them will say that it slows down execution, because PHP has to stop 
the execution, go back to the compile stage and then go back to the 
execution.

The second problem is that a name of someone who might be respected and 
used as an official source for PHP and WordPress is referenced in that 
comment giving credibility to the comment when none should have been 
given, since it is all rubbish. It is idiocy to even consider what was 
written in the comment and yes, it was trolling, but I really would like 
to understand what in your mind you figure it to be true and why you 
wish to expand the myth to others. I'm telling people that when they see 
this myth to not believe it.

Where I believe it comes from is the extremely rare cases with many 
files and slow systems where the conditional is faster, but on hosting 
servers the CPU and file systems are generally fast enough without the 
latency that is on test systems it isn't and never will be. Furthermore, 
you can find many sources where those who develop opcode caching 
extensions speak about the failure to consider how the conditionals 
adversely affect those extensions.

Myth 3: $end-$start in a loop equals total overhead.

The science of this is inconclusive and should never be used for full 
analysis. Profiling involves xdebug and cachegrind for PHP and other 
profiling tools depending on what you are measuring.

Fact 1: When in doubt, Research it.

I'm not saying you take my word for it and without sources (I'm not 
going to spend the hours it is going to take, just to be ignored again), 
you should be doing the research yourself or the testing yourself, using 
ab, xdebug and cachgrind, etc to get the accurate results. There are 
also opcode tools in order to see the opcodes, although it is anyones 
guess how much overhead each opcode has, but generally less = more, but 
not always.

Jacob Santos

[1] To accurately tell, you would have to profile the re2c parser (for 
PHP 5.3+) or Flex for before. Something that common sense should have 
been a given, but still have to argue with various people about (not 
just in WordPress circles).

[2] Something that is probably still debated by those who really desire 
and need performance to the extreme but for the majority of people the 
advantage of comments is far better than the tiny amount of

[3] http://core.trac.wordpress.org/ticket/10493#comment:4