From: Godmar Back (gback@cs.utah.edu)
Date: Fri Dec 11 1998 - 15:13:54 EST
>
> On Dec 11, 1998, Godmar Back <gback@cs.utah.edu> wrote:
>
> >> optimize empty finalizers away, step 1.
>
> > Btw, this had brought down the library compile time from 28 to 26 seconds
> > again. (Still my unofficial performance measure).
>
> Great!
>
> > The next step, of course, is to avoid calls to finalizeObject at all.
>
> Do you really think this will make so much difference?
Well, it will make some difference. I think the soft_instanceof calls
to check for thread classes add up.
At creation time, the check is only reading a flag in the class structure.
Very fast.
>
> If the issue is avoiding the function call, we could move the test to
> the finalizer loop, and this should really save us some cycles.
No, the point is to avoid that they're even moved to the finaliser list.
We should be able to free them right away. (see gcMalloc)
So, basically, the empty finalizer, nothread objects won't even be
seen by the finalizer.
The empty finalizer, thread objects will be seen and finalizeThread
is invoked on them.
The non-empty finalizer, thread objects will be seen and the finalize
method plus finalizeThread is invoked on them.
The non-empty finalize, non-thread objects will be seen and ONLY the
finalize method is invoked on them without checking everytime whether
they're threads -- cause they're not.
We'll see how much it gives if it works.
- Godmar
> However, I'm not sure creating new allocation types will save us much,
> since the test of which allocation type to use will have to be
> performed either at object allocation time or finalization time. I'm
> not sure how much moving this test to allocation time would save, in
> terms of processing of the finalization list. Maybe it's worth a try,
> but I don't expect as much improvement as this first step.
>
> --
> Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
> oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
> Universidade Estadual de Campinas, SP, Brasil
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:12 EDT