[fedora-java] [Patch] Improving gcj-dbtool performance

[Andrew Haley]

Ziga Mahkovec writes:
 > On Fri, 2005-03-11 at 10:29 +0000, Andrew Haley wrote:
 > > Ziga Mahkovec writes:
 > >  > Maybe this could be further improved by creating a single separate map
 > >  > for all new jar files (utilizing a new "--unsafe" gcj-dbtool switch
 > >  > which triggers the behavior in the patch).  Then, only two maps would
 > >  > have to be merged, avoiding the need to create 150 separate maps.
 > > 
 > > What's the problem with creating 150 separate maps?  I don't get it.
 > 
 > Fragmentation I guess.  Each new map would have to over-allocate enough
 > space for a jar file to avoid resizing.

No, I don't think that would be a problem.  Each file will be sized to
be just big enough, and the resulting merged map will also be just big
enough.  (The existing code could be made more efficient, I grant you:
it's silly to create a small map that instantly gets resized.)

 > And somehow a single map seems like a cleaner solution.  But those
 > are minor issues.  Any improvement over the current situation would
 > help.

It should be just fine.  Try it.

When used as I describe, almost all of the time is spent reading the
jar files, not creating the maps.  There's nothing you can do about
the maps that will make the process any faster.  When building jonas,
which has 28871 classes in 239 jar files, the whole process takes
1m1.140s on my box.

I am very loath to add "unsafe" flags to any program, particularly
when there's a simple alternative.

Andrew.