> could someone explain to me why there are two stacks > of apr_sms_trivial, such that you get the double > list-walk in the first place? > > please? :)
Ok, this is due to the way we have created the patch to allow sms to be used instead of pools. We chose the "trivial" sms as the replacement for _all_ pools, except the top level one. [You can see this in the hierarchy charts I put up this week]. > is there a good reason why apr_sms_trivial is not > using apr_sms_general to obtain its memory? Yes, to hold the hierarchy. Another option would be using "tracking" instead of "trivial". > surely, to get blocks for a child directly from > malloc [via apr_sms_general] would be better than > going to another apr_sms_trivial, which, as the > stats show, does yet another list-walk? See above. > also, would someone like to write an apr_sms_trivial_using_hashchains? > > the idea here would be that the size of the memory block > is used as a hash-lookup into the currently-available free chain, > instead of list-walking. > > surely, that saves time, yes? How would you take care of block sizes that are only differ a few bytes in size? How do you satisfy a request for X bytes when you don't have a block of X bytes, only larger or smaller? > anyone care to refute this hypothesis and proposal? :) Sander
