Hello Stanislav, Tuesday, September 2, 2008, 9:51:38 AM, you wrote:
> Hi! >> The problem is that the loading/unloading of the scanner and parser can >> be significant overhead, and by cramming all code into a single file, >> can result in a 10%-30% performance improvement over code in separate >> files, even with an opcode cache. This has been verified independently > Not only this, but the fact that executing 50 different op-arrays, with > all setup and teardown that happens on the way, is definitely slower > than 1 op-array, and also the fact that early binding on compile stage > may be a bit faster when we are dealing with a lot of classes and > carefully arrange them. > As always, note that the benchmark was loading huge amount of classes > and doing nothing but, so don't expect your real-life app to get > anywhere near 30% on that. Actually, I have no idea how hard it would be > to make big app using a lot of modules and lot of different classes in > different modules to work this way, so I'm not even sure it's practical > or will give any benefit - since you might be loading a bunch of code > you'd never need. But the effect does exist. My guess is that it allows for development with heavy __autload usage and then doing deployment based on static analysis where each target page results in one large php file generated from that analysis. So there won't be any overhead and each script target would be a single target of its own. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
