Re: [PHP-DEV] Method call improvements
(for the fun of it, I am CCing Andi, the CTO and senior VP of Zend) On Sat, Jan 17, 2009 at 21:17, Marcus Boerger wrote: > Hello Timm, > > Friday, January 16, 2009, 9:35:13 PM, you wrote: > >> * At [1d], calculate a hash key for the following: >> - method->name >> - ce->name >> - EG(scope) ? EG(scope)->name : "" >> These are the only variables used for verifying scope and >> modifiers, and the verification is always going to yield the >> same result as long as the stay the same. > > Aren't we able to bind these at least partially to the function call > opcode, in case we know they are constant? If all is constsnt we could > even store the whole lookup in the opcode. Well you'd have to convince > Zend to do that because os far they have always been against this > approach. Wait what? Wtf? Why would an opinion from a company matter to us? Sure. Dmitry does a kickass good job, but I can guarantee you that Arnaud, Felipe, Tony and youself could do just as good job. If I was king (with m4d skillz) I would fork that "Zend engine", try to fix the license (which lies, there is no way of "downloading the engine" from their website) and try to optimize things as much as possible before it ever hits (almost non-existing) optimizers. By saying this kind of things Marcus you make me very scared. You shouldn't care what Zend, Yahoo, Facebook or whatever company says. If you think it is the right decision then (quoting Christina Aguilera ;) ) "Do your thing honey!" You were well on-track with your Closures commits, unfortunately that didn't turn out quite as well neither of us had hoped for, but that is life. Sometimes your ideas don't work out. Sometimes they do. It hasn't stopped you so far, so why would it now? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/spl spl_observer.c
On Sat, Jan 17, 2009 at 21:57, Etienne Kneuss wrote: > Hello, > > On Sat, Jan 17, 2009 at 9:10 PM, Marcus Boerger wrote: Maybe you two should stop adding features for few days and document all this crap so people know what the fuck is up? I am getting really annoyed by this extension. There are maybe 15 people in the entire world that know what the extension offers, and maybe 3 that actually use it. If you two would help documenting it I would bet you would see 15.000% more people using all its features. And no Marcus. The fuckedup doxygen crap is not documentation. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prototyping
Hello Stanislav, Wednesday, January 14, 2009, 5:29:02 PM, you wrote: > Hi! >> That is one example of convoluted code that is already possible. If a >> developer creates such a mess is his fault. > "Convoluted"? "Mess"? Are you kidding me? It's standard usage of access > handlers. It is a mess right now. You assign a closure to another method and get access to the original owners private members. That is not only unexpected and contradicting anything that any oyther language ever but but also violates our very own basic ideas. That is what I call a mess. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
Hello Timm,
Friday, January 16, 2009, 9:35:13 PM, you wrote:
> Hi,
> in every programming language, method calls are expensive. Especially in
> PHP, which does not spend any effort during compile time to resolve method
> calls their target (and cannot due to the possibility of lazily loading
> classes using include w/ variables). I recently did some performance
> profiling on exactly how slow method calls are compared to other operation
> such as, for example, incrementing an int (the factor is around seven) and
> how they compare to compiled languages (the factor lies between 400 and
> 1400).
> Here goes the test:
> $instance->method();
> ...in different variants, using public, private and protected (the latter
> are the slowest). On my machine I get about somewhere around 700'000 method
> calls per second, while C# scores 250'000'000, for example. Your mileage is
> going to vary.
> The difference in these numbers being quite discouraging, I started digging
> a bit deeper into how method calls are handled by the Zend Engine. Again,
> let's take the example from above, here's what happens (in zend_vm_def.h and
> zend_object_handlers.c):
> 1) Finding the execution target
> a. $instance is a variable, so we have a zval*
> b. if Z_TYPE_P() of this zval is IS_OBJECT, OK.
> c. Z_OBJCE_P() will render the zend_class_entry* ce
> d. method is a zval*, its zval being a IS_STRING
> e. Given ce's function_table, we can lookup the zend_function*
> corresponding to the method entry by its (previously lower-
> cased!) name
> f. If we can't find it and the ce has a __call, go for that,
> else zend_error()
> 2) Verifying it
>a. If the modifiers are PUBLIC, OK.
>b. If they're private, verify EG(scope) == ce. If they match,
> OK, if not, try for ce->__call, if that doesn't exist, error.
>c. If they're protected, verify instanceof_function(ce, EG(scope))
> If that returns FAILURE, try ce->__call, if that doesn't exist,
> error. If it exists, OK.
> 3) Insurance
>a. Finally test if the zend_function* found is neither abstract
> nor deprecated.
>b. Test non-static methods aren't called statically, else issue
> a warning (or error, depending on the situation).
> 4) Execute
>a. Take EX(function_state).function->op_array and zend_execute()
> it.
> You can clearly see the checks in #1 and #2 (most of which happens in
> zend_std_get_method())are quite extensive. Now the idea I developed was to
> cache this information and I thus came up with the following:
> * At [1d], calculate a hash key for the following:
> - method->name
> - ce->name
> - EG(scope) ? EG(scope)->name : ""
> These are the only variables used for verifying scope and
> modifiers, and the verification is always going to yield the
> same result as long as the stay the same.
Aren't we able to bind these at least partially to the function call
opcode, in case we know they are constant? If all is constsnt we could
even store the whole lookup in the opcode. Well you'd have to convince
Zend to do that because os far they have always been against this
approach.
Also the zend_class_enty lookup in [1c] imo is completely useless. If
the zval object would store the class entry and the class entry had a
pointer to the handlers then we would save another costly lookup and
simply follow a pointer instead.
Even more we could have the object id be a pointer into the object
storage or a direct index into the storage (like we have right now).
But something that does work faster and does not need so many function
calls. If we go for a pointer we can easily provide a means to resolve
that pointer into an object id for the one case we need an object id,
which is var_dump().
Then your hash table sounds like a nice idea.
> * Look this up in a hashtable (in generic-speak:
> HashTable). If found, return that,
> continue with [1e] otherwise.
> * After [2c], store the found zend_function* to the hash.
> I was curious how this would affect overall performance, both in synthetic
> and in real-world situations. The first tests I ran were something along the
> lines of:
> for ($i= 0; $i < $times; $i++) {
> $instance->method();
> }
> ...with and without the patch - this gave me a factor of 1.7 to 1.8 (times
> the PHP I built with the patch was faster)! The real-world situation was
> running the test suite of an object-oriented PHP framework, taking 1.55
> seconds before and 0.91 after. I would call this good, almost doubling the
> speed. Of course this is nowhere near the factors I mentioned before but I
> think this has potential. Of course, caching comes at a cost, but by using a
> numeric key instead of a string I could reduce the overhead to a minimum,
> the real-world application consuming about 20 KB more memory, which I'd call
> negligible.
> Last but not least I verified I hadn't utterly broken the way PHP works by
> running the tests from
[PHP-DEV] Really Need..
Afternoon all, Recently I've been running in to a lot of frustrations with PHP, don't get me wrong I love the language, but I just can't do what I *need* to in a few situations, specifically when dealing with Classes and Objects. I strongly feel that these need added in to PHP 6, for multiple reasons which I'd be happy to elaborate on. a: Optional Static Typing I'm finding an ever increasingly need to be able to staticly type properties, parameters, return types etc (in classes) I know there is type hinting but it's just not enough to do what one needs. Additionally support for staticly typing primatives. b: Object superclass A base class type which all objects automagically extend, with (if nothing else) a unique id / hashcode for each object. Failing this some form of function to get a unique reference string for any variable. c: Method overloading TBH it's something I could live without, whereas a/b aren't, but it would be an ideal addition to php; Many times I've had to work around the lack of this functionality with (what could be) unneeded code. I can't stress enough what a vast difference the implementation of these three features would make to php, even above many of those currently rfc'd (imo), infact I'd put them on par with the need for namespaces, and additionally they'd compliment namespaces perfectly. Is there any way to get the ball moving with any of the above? (if I was a c dev I'd do it myself.. infact even considered learning c just for this task) Regards, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32
On Sat, 2009-01-17 at 14:06 +0100, Sebastian Bergmann wrote: > Pierre Joye wrote: > > Yes, they have to be rebuilt. I will do it for Windows. > > I may have not expressed myself cleary: I did rebuild Xdebug against a > build of PHP_5_3 with the new buildid. The resulting xdebug.so cannot > be loaded. fixed. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32
Pierre Joye wrote: > Yes, they have to be rebuilt. I will do it for Windows. I may have not expressed myself cleary: I did rebuild Xdebug against a build of PHP_5_3 with the new buildid. The resulting xdebug.so cannot be loaded. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32
hi, On Sat, Jan 17, 2009 at 9:04 AM, Sebastian Bergmann wrote: > Stanislav Malyshev wrote: >> stas Sat Jan 17 02:05:14 2009 UTC >> >> Added files: (Branch: PHP_5_3) >> /ZendEngine2 zend_build.h >> >> Modified files: >> /php-src/win32/build config.w32 >> /php-src/ext/standard dl.c info.c >> /ZendEngine2 zend_extensions.c zend_extensions.h zend_modules.h >> Log: >> Build IDs > > Is it intentional that extensions such as Xdebug (cleany built built > from source against PHP_5_3) do not load anymore now? Yes, they have to be rebuilt. I will do it for Windows. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32
Stanislav Malyshev wrote: > stas Sat Jan 17 02:05:14 2009 UTC > > Added files: (Branch: PHP_5_3) > /ZendEngine2 zend_build.h > > Modified files: > /php-src/win32/build config.w32 > /php-src/ext/standard dl.c info.c > /ZendEngine2 zend_extensions.c zend_extensions.h zend_modules.h > Log: > Build IDs Is it intentional that extensions such as Xdebug (cleany built built from source against PHP_5_3) do not load anymore now? -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
