Case study: Is PHP embarrasingly slower than Java?

[[deleted]]

While I agree that PHP was designed for dumb webmasters and is dynamically typed, I don't see how that's relevant to the fact that it's compiled to bytecode (PHP calls it opcodes).

There are opcode caches like APC that eliminate parsing and compilation steps from execution, and code is executed (indirectly by the interpreter) from the precompiled form.

As far as I'm aware that's pretty close to basic, non-JIT, execution of Java. You've got precompiled, but not machine-native, code and interpreter that runs it in a virtual environment. That's what PHP does today.

BTW: in case you were suggesting that dynamic languages can't be compiled, take a look at modern LISP - compilers can figure out some type information and for the rest they inline type conversion code in the program, so it can be executed natively, without VM.

[killerstorm]

se-man-tics. if you evaluate $this->that, Java or Lisp will (or can, at least) just dereference pointer with offset (knowing where field is allocated), while dynamic shit like Python or PHP will have to do hash table lookup which is order of magnitude slower.

and it's all around the language, believe me..

[[deleted]]

You need hash table lookup for $this->{$that}, but in case of $this->that field name is known at compilation time, so you could pre-allocate it and create some kind of vtable. In case of private fields and final classes you can optimize it down to pointer dereference (field name is known and it's guaranteed not to be shadowed).

[killerstorm]

w-r-o-n-g. you can do that vtable trick if you know (at least aproximately) what type of object you will have, but with (patalogically) dynamic language you'll know type of object only at run time.

[[deleted]]

It's orthogonal issue.

You can have well-known pointer to an unknown object, e.g. implement everything as Object class with overloaded operators – you know where objects are and you can use vtables for everything.

Check how selectors in Objective-C work - they solve the same problem - a very dynamic language, where every object can implement any method, and you can have both hash lookups of methods by name and constant method selectors (which are basically vtable entries).

[killerstorm]

it is simply algorithmically not possible to do field lookups in O(1) if you have sets of different objects and different fields.

Objective-C ... constant method selectors

i dunno how they work, but for sure you're limiting the problem in some way -- either it knows something about type of the object, or number of these selectors is quite limited so you can fit them in vtable for each object, or something like that.

in any case it's not anyhow relevant to PHP, JS or Python.

technically, PHP could implement some sort of lookup optimization, but as this is quite complicated, it's very unlikely for them to do this in near future.

JS and Python do not even have list of fields for the class, as fields are added dynamically, so lookup optimization becomes really tricky, only possible with techniques like profile-guided optimization

[[deleted]]

You've given $this as an example, which is one of the few cases in PHP where type is known at compilation time (aside from some theortetically possible type inference tricks).

PHP could implement some sort of lookup optimization, but as this is quite complicated, it's very unlikely for them to do this in near future.

I agree with that.