Graham Kelly wrote: > Overall though, more often than not PHP is not the bottleneck of your > program and thus optimization wont get you too much.
In a lot of ways, PHP is already well-optimised. The hash tables are fast, the executor is decent, as executors for weakly-typed languages go. Many internal functions have quite reasonable C implementations. Given this, sometimes it's easy to forget that PHP is pathologically memory hungry, to the point of making simple tasks difficult or impossible to perform in limited environments. It's the worst language I've ever encountered in this respect. An array of small strings will use on the order of 200 bytes per element. An array of integers will use not much less. A simple object (due to being based on the same inefficient data structure) may use a kilobyte or two. Despite the large amount of time I've spent optimising MediaWiki for memory usage, it still can't run reliably with memory_limit set less than about 80MB. That means you need a server with 500MB if you want to set MaxClients high enough to let a few people use it at the same time. So if it were my job to set priorities for PHP development, I'd spend less time thinking about folding constants and more time thinking about things like: * Objects that can optionally pack themselves into a class-dependent structure and unpack on demand * Exposing strongly-typed list and vector data structures to the user, that don't have massive hashtable overheads * An oparray format with less 64-bit pointers and more smallish integers That sort of thing. -- Tim Starling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
