Actually, it's an expected tradeoff of interpreted languages.
Compilable languages have both a compiler and a linker that bundles
everything in one executable. By using bytecode caching and bundling
you're just getting closer to the performance expectations of a
compilable language. But bundling is not as easy as it seems, and its
complexity is proportionally inverse to the complexity of the language.
As much as you can try to improve this area, you can't do much without
resorting to hacks and workarounds. An option is becoming a
managed-code language such as Java or the .Net family.
If your already doing bytecode caching how much benefit is there to bundling?
In that case it seems the main slow downs would be the minor time involved in
any actual system calls and whatever logic is done for imports. Unless you have
a slow file system I can't imagine the actual file reads from disk being to big
an issue. I have my file system keep a lot of stuff in RAM so that the disk
doesn't actually have to be accessed very often. I do a lot of none-PHP
programming that involves heavy file use and keeping it all in RAM makes it a
lot faster. I can't see PHP making huge gains but they might help for people
really worried about performance.
With my current project I sadly have to interface to a slow back end system
that is a commercial ERP product so I can't do anything to speed it up
directly. Very annoying. The best I can do is cache as much data as possible.
We're dumping a buttload ($30,000+) of money into a new AIX server for the back
end to try to get it up to a decent speed.
I'm a firm believer that it's better to throw more CPU power at a performance
problem than to make code less maintainable. Just buy a faster server.
--
Michael McGlothlin
Southwest Plumbing Supply
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php