On 12/16/06, Richard Lynch <ceo@xxxxxxxxx> wrote:
On Fri, December 15, 2006 3:32 am, Kai Xiang wrote:
> Oh, that's interesting to know, is that from certain test of design
> goals? I
> suspect this for I thought the most time-consuming work in PHP should
> be
> compiling.
The most time consuming work in PHP isn't in PHP at all. :-)
It's in the database, the file system, the network congestion...
It's true, that for the core of PHP, for what little time is spent by
PHP doing anything at all, compiling the code to opcode takes longer
than ripping through those opcodes and dispatching the function call
to some external library, not counting the time spent outside of PHP
core actually executing whatever that extension library does.
That still doesn't mean that the actual process of converting PHP
"echo" to opcode #42 takes any large chunk of time. It's very tiny.
> Refer to the early descussion, because all the thread share the same
> opcode, so it could save memory usage at the same time, is that true?
> say if
> there is a lot of requests at the same time, that could be a lot of
> memories. is that the design goal? or why not just implement a PHP
> file
> cache.
Because if you just did the file cache, it would be an equal amount of
work to doing the opcode cache, so you might as well go ahead and
cache the opcode, and save that extra 1% performance.
Caching the parser output as opcodes instead of raw PHP input is like
free gravy. :-)
It's a question of inserting your cache calls in line 1470 or line
1530, and you either cache the PHP source at 1470, or the opcode
output at 1530. So you do it at 1530 and save those lines of code in
between that do the opcode translation.
[line numbers used for illustrative purposes, and are not actual line
numbers, nor even realistic range between them]
That's really useful information, thanks
> 2. Is there some alternative choise except zend engineen, why need
>> a
>> > zend
>> > engine? for performance advantage or just easy for porting to
>> > different
>> > platform?
You could, in theory, take PHP, rip out its guts (aka the Zend Engine)
and replace it with some other compiler/parser/engine that did much
the same thing, if you had nothing better to do with your life for the
next several years...
I'm just curious, I'll save more time for fun... :)
The Zend Engine is what translates:
if (...){
myfunction(...);
}
into something that the computer can actually execute.
That's pretty much all it is.
Note that the Zend Engine is OPEN SOURCE and it will always be OPEN
SOURCE and it will never not be OPEN SOURCE and it is FREE and it will
always be FREE and it will never not be FREE (*) for PHP.
But, sure, if you feel strongly enough about it, go ahead and fork the
PHP project to rip out the Zend Engine and write your own.
[shrug]
That's why it's Open Source, to give you the freedom to do that.
Seems like an awful lot of work to no real purpose to this naive
reader, but to each their own.
(*)
Actually, if somebody wants to embed the ZE inside of something other
than PHP, then I think Zend expects to get paid for that. I do know
they had a deal or two on the table when I worked for them, back in
2000 or so, but I dunno if they came to fruition or not. ZE may well
be embedded in some telecom gear somewhere, as it would be a good fit
for a simple scripting language that is small enough (without
extensions) to fit in that niche market. And the telco industry can
afford whatever Zend charged them for that, most likely.
Yes, we know there is a possibility that Opensource can make money, and
bring value for those who don't want to pay at the same time..
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
