Re: Idle Rambling : Strings, Allocation Granularity and Efficiency ...

One thing which is a possibility is always to always allocate strings in blocks of n (where n could be 4 or 8 or something like that). I think it would definitely help the memory cache to reach better results but I haven't had time to mess with it and I'm not sure when I'll have time. Andi At 10:52 PM 6/7/00 -0400, clayton collie wrote:

im not sure if anyone has given thought to the pattern of usage of strings in PHP, though it seems to me that strings in a server-side scripting language would probably be one of the most heavily used types. As a consequence, i assume that they are subject to constant allocation and reallocation, from every concatenation to modification by functions.

    ive always wondered how this usage pattern would affect memory usage

over time, and forgetting for the moment the possibility of memory fragmentation, what would be the implications for efficiency, especially under load.

    i use Delphi in addition to C and one of its niceties, IMO, is its

native string handling, which goes beyond even VB<g> in its implementation. Every string is reference counted, using copy-on-write semantics, so you can merrily copy a 1G string 10,000 times without consequence. PHP does this too, of course (ref counting). The other efficiency comes from the fact that Delphi string allocation has a granularity of about 8 (i think). That way (smaller) concatenation operations arent always haggling the memory manager. At the beginning of each string (at a negative offset from the user accessible area) is a refcount, length count, and a capacity field, which shows how much memory was actually allocated for the string (the length gives how much was consumed by string data). These two features makes strings zippy, but then the compiler has built in support for them.

    Like the title says, this is just random musing about how a scripting

language like PHP can benefit from such an approach (not that i expect it), or even the more fundamental question of whether the approach is even necessary. clayton -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

--- Andi Gutmans <andi@zend.com> http://www.zend.com/