On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> > Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> >
> > > The problem is, that it does not give any speedups (it is almost
> > > completely compile-time neutral for compilation of preprocessed
> > > gcc sources). I will check whether moving also edges to pools
> > > changes anything, but so far it does not seem very promising :-(
> >
> > Does it make any difference for gcc.c-torture/compile/20001226-1.c?
> > And of course it won't make any difference if you have enough memory
> > that you never need to garbage collect without your patch.
>
> I was wrong to say that. It could make a difference even if you don't
> garbage collect, since the allocation will be cheaper. But that is
> likely to be a relatively small effect.
actually, the expected speedup was mostly supposed to come from better
locality. The speed of garbage collection should be about unchanged.
Regarding the speed of allocation, pool_alloc might be slightly faster,
but probably not significantly.
Uh, structures as big as basic_block won't get better locality by placing
them near each other. But maybe I'm missing something ;)
Richard.
