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

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