On 06/07/2005, at 3:43 PM, Rasmus Lerdorf wrote:

  The GOTO mechanism uses a bit of a compiler trick known as
"computed gotos" to try to make each one a very simple branch at the
assembly level.  It looks like this in C:

That is, we can dynamically create a list of labels and then use a GOTO
to jump directly to one of these dynamic labels. Not instead of jumping
to ptr[1] as in the above example, imagine making that a variable, say
the opcode number, and doing the goto directly to the code defined for
each opcode.  That's the GOTO VM.  And it should theoretically be the
fastest assuming the compiler does the right thing.

Very interesting, I am not a C man however I am getting my head down into extension building coz I am familiar with it, even though how low level down to the registries it is, there are helper functions in the Zend core to do some work for you :) I would presume GOTO to be quick as its using labeled references.



The SWITCH vm was originally just a big switch(opcode) { case 1: ...;
case 2: ...' } It's a bit different now, but you can think of it in
those terms.  Decent compilers should theoretically be able to optimize
a clean set of cases to something close to simple branches, just like
the computed goto case, but it can be hit and miss.  With the computed
goto way of doing it, we are trying to send a stronger hint to the compiler.

Well i do find a performance issue running a heap of switches in PHP so I could presume the same here.



And finally the CALL vm basically just uses a function pointer to call
the handling code.  Think of it as something alone the lines of
${"handler_$i"}(); in PHP terms.  That is, you would have handler_1(),
handler_2(), handler_3() functions defined and you dynamically determine
which one to call based on the opcode.


Ahh like a dynamic callback interesting, I would prob find this the quickest then ? I do find it more efficient to run callback functions than switches in the php code which I have been doing for a while now.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to