From: David Abrahams (dave_at_[hidden])
Date: 2004-08-11 09:58:18
Toon Knapen <toon.knapen_at_[hidden]> writes:
> 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.
Yes, and it should be clear from the code that it holds. At least,
it was for me.
> Adding 'assert( self->size == self->capacity )' I
> get an assertion failure during the bootstrapping though.
Oh? Can you give any more info? What's the stack look like?
> 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
Not at all; it's a good idea.
> Of course I will always request approval of a patch on the ml before
Go ahead and commit, but do post a notice. I'll clean up any mistakes.
>>>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)
Perforce Jam used lots of fixed-sized buffers that would occasionally
overrun, which is why I added this string "class". The opt
buffer was designed to keep most of Perforce's performance while
> 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?
Not me, but I'm pretty sure Volodya did.
> 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.
I don't know. If there's a bug in string it should be fairly
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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