Re: Re: Typed properties patch

On 04/19/2016 10:53 PM, Stanislav Malyshev wrote:

Hi!

More properly - PHP is done in a way that doesn't allow big data processing yet :) LuaJIT may be used for in-kernel packet filtering...

But we're not targeting PHP for in-kernel packet filtering. And we should not sacrifice language semantics for minuscule gains in performance. Especially given that banning unset by itself will achieve nothing - you also have to deal with lots of other ways object can be initialized. OK. In my opinion, if something is defined as "int" should be always "int". Nor "null" neither "undefined".

This is good for programmers who think like me, for compiler and for hardware CPU :) You have another opinion, and we won't persuade each other. Lets stop this discussion, because everyone who read already understood both point of views.

Run bench.php with CALL and GOTO VM. You'll see 20-30% performance difference caused by branch miss-prediction.

That's whole VM, not one branch which is never taken. Yes, this is just an example how branch miss-prediction may affect performance.

I think, If we may eliminate checks we should do it (at type-system design level).

I don't think we really can without introducing some very strange limitations, like banning unsets or limiting serialization or introducing special magic methods that are optimized differently, etc. Personally, I think we can,

but if we can't provide type safety for all cases, we shouldn't try to do this for some case, shouldn't name this "typing" and shouldn't perform type checks at all. Lets name this "type annotations" and don't perform run-time type checks (like HHVM Hack do). Thanks. Dmitry.