performance/garbage collection

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-11-20 02:01:08

[moving to jamboost]

Rene Rivera wrote:
> [2003-11-19] David Abrahams wrote:
> >Rene Rivera <grafik.list_at_[hidden]> writes:
> >> I know, from experience with my own project, where that slowness comes
>
> from.
>
> >> A very large portion of the "startup" slowness comes from the numerous
> >> memory allocations bjam does. The reason it does is because of the way
> >> it allocates once only read only strings, and we allocate many, many
>
> strings. I
>
> >> tried making the strings garbage collect once, but only succeded in
>
> getting
>
> >> crashes from using deallocated memory :-(
> >
> >We maybe oughta try throwing the Boehm collector at it. But remember
> >that it also interns all strings, so any strings that are duplicated
> >get shared. I'm not sure how that would balance out.
>
> Hmm, it might be worth trying out. bjam already tries to implement a fairly
> bad garbage collector... bad enough that the freeing collection part of it
> is disabled ;-) So at minimum it just reuses equal strings.

I thought about it previously and considered adding garbage collection to bjam 
a non-trivial excersice. Sufficiently non-trivial so that I decided I won't 
do it. Of course, it would be nice to have, but as far as V2 is concerned, I 
suspect that I might rewrite all performance-critical parts in C soon ;-)

Besides, according to profiler, the most time-consuming part is the hash 
lookup. I'm not sure how faster it will become with gc.

- Volodya