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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
