I forward here some comments from CC requested by Andrew
"VE: How the objects per page impact the behavior/performances of the b_heap? AS: I think that there may be a serious design flaw here. The number of objects per page should depend on the size of the object--much like the implementation of deque.
I think that you should be able to find a function that derives this value based on the size of the object and the cache properties of the host machine. A non-trivial, but I think important feature.
This discussion should be elevated to the mailing list.
In retrospect, "serious design flaw" is not a good description for this issue :) but I think that this is important to address. I was going to bring this up today. My suspicion is that allowing users to freely specify the number of objects per page could lead to performance degradation if they choose unwisely. I further suspect that you can formulate some heuristic that optimizes choice size of the object. I'd look at GCC's deque and see what what's going on there. LibC++ takes employs a similar heuristic. Cache properties will also impact performance related to this choice, but I think that information is not always available at compile time. Also, I think that cache properties matter more as the size of the heap gets large, so it may not I'm not fundamentally opposed to allowing customization of this parameter (in order to support experimentation), but I think that the default value should be derived differently. Also, the documentation must explain why the parameter might be varied, and in general why it should not. Andrew