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

Reply via email to