From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2004-08-11 09:35:40
David Abrahams wrote:
> You're missing the fact that extend_full is only called when size ==
Do you mean that self->size == self->capacity is a precondition for
calling extend_full. Adding 'assert( self->size == self->capacity )' I
get an assertion failure during the bootstrapping though.
To avoid misintrepretation of what the different functions do (for
myself but also for people that will be looking at the bjam sources in
the future), would you mind if I add documentation to the function
declarations describing the functionality, pre- and post-conditions? Of
course I will always request approval of a patch on the ml before
>>Can't we rely on small-object-allocation optimisation of malloc as many
>>compilers do now for the new operator?
> I doubt it. There are lots of bad mallocs out there and many std
> libraries still implement the small string optimization. But do the
> benchmarks yourself if you want to know.
I checked the waste (of not using opt but instead mallocing) and the
total amount of memory consumed by all non-used opt's is very small
(actually during most of the build process at most 2 strings longer than
32chars were allocated. This surprised me. Or my instrumentation of the
code was wrong (which counted the number of strings in memory) or bjam
is constantly creating and deleting strings)
OTOH I have done timings for malloc with gcc/linux, icc/linux and
visualage/aix. Seems like gcc and icc both implement
small-object-allocation-optimisation up to objects of 64bytes whereas
VisualAge does not.
> I think you're looking in the wrong place.
Possibly. This is the first time I really dived into the bjam source
code. But have you run valgrind on bjam? If so, did you got warnings
from valgrind or not? Because I wonder if I have done soth wrong that
made that my bjam seg faulted.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk