> On 23 Sep 2001, Stig Sæther Bakken wrote:
>
>> [Jeroen van Wolffelaar <[EMAIL PROTECTED]>]
>> > In PHP performance is IMHO a bit less important than in DBMS's. If
>> > you're after performance you shouldn't use a scripting language
>> > anyway :).
>>
>> Sorry for starting, but this is just nonsense.
>>
>> First of all, today PHP is a scripting language only by
>> categorization, technically it is no more so than Java.
>
> I thought a scripting language is differnt from a non-scripting
> language in that a scripting language will be compiled at runtime?
> True, java has a JIT-compiler (Just In Time). But I don't know much
> about this, so simply correct me if I'm wrong :-)
While I do not know what the running definitions these days. There is pure
interpreted code, i.e. where no compilation takes place.
Then there are interpreted languages which compile into tokens, and
interpret the tokens.
Then there interpreted languages like java where the compile to token step
is executed by the user.
Then there are additions to langauges like java where the tokens are "just
in time" compiled into native code.
Of course there are compiled languages where source is compiled into
native machine code.
I'm not sure what category I'd put "scripting languages." Something like a
shell script is purely interpreted. If we call "scripting languages" as
those which are purely interpreted, then PHP is not a scripting language.
>
>> Second, performance is important for PHP. 4.0 beats lots of
>> competition because of its performance. We shouldn't even think of
>> jeopardizing that.
>
> Performance is important indeed. (originally I said: "perfomance is a
> bit less important _than in DBMS's_", and everybody knows that in
> DBMS's, performance is extremely important) I expressed myself a bit
> unhappy, I think - I'm not sure - that the performance impact of slower
> arithmetic etc on PHP-integers would be neglectible. String
> manipulation is much more expensive.
>
> Also, definitely not ALL integers in the C-code need to be converted to
> 64bit of course, only those which are (derived from) PHP variables.
>
> Most registers for example can remain 32bit. To name one
> example, the capacity of hashtable and thus max number of entries in it
> will remain expressed in 32bit integers.
>
> But there will be a lot of integers needing to be converted, and again,
> I don't know the performance inpact. If it are multiple percents, I
> think it's not an option.
>
PHP is a fairly large system now. It isn't trivial to make changes like
this. If one compiles PHP on a 64bit system, then 64bit numbers could come
for free. Moving a complex system from a native register width to an
artificial construct like "long long" is always a big deal, a huge
regression test would be needed for any reasonable amount of quality
control.
I spent a lot of time making 16bit Windows programs deal with 32bit
numbers and addresses, and before that I spent a lot of time implementing
16bit arithmatic on an 8bit Z80. There are always a huge number of things
you would not have expected to happen.
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
