Hi Mike > We have three memory_pools: memory, string, and constant_string. Is there > any reason that string and memory are distinct? (aside from code > simplicity).
> Seems to create a lot of duplicate logic with the need to support a string > version and a generic buffer version of everything, when they are so > similar. One difference is that my private version of compact_string_pool contains code for COW strings, which means the actual compaction code is significantly different. Steve Fink has suggested merging the two with the use of flags to differentiate the behaviour; obviously, with no COW code in the live version, compact_string_pool could just be scrapped, and the string header pool added (index -2 ?) to compact_buffer_pool. Another difference, instigated by Dan when he proposed this split in the first place, is that the alignment factor for the string pool is smaller than that for the buffer pool. A side effect of the split pools is targeted compaction i.e. the buffer pool gets compacted only when it is full, and the string pool likewise - this does provide a performance benefit in situations where one pool grows regularly and the other does not. If we were to eliminate the separation of pools based on type, perhaps we need to consider some other means of having multiple pools, purely for performance reasons. This could, for example, be based on the buffer header size, so each resource pool would have its own memory pool. -- Peter Gibbs EmKel Systems
