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

[Andrew Haley]

Ziga Mahkovec writes:
 > On Fri, 2005-03-11 at 10:02 +0000, Andrew Haley wrote:
 > > Ziga Mahkovec writes:
 > >  > This seemed a bit unusual and after inspecting the gcj-dbtool sources, I
 > >  > found out that in resizeMap(), a new PersistentByteMap is created for
 > >  > each jar package that is added -- amounting to almost 150 several-MB
 > >  > temporary files created.  I don't think this was intentional.
 > > 
 > > This is wrong.
 > > 
 > > Other running applications may be accessing a .db file while it is in
 > > place, and it is not safe to modify it.  The right technique is to
 > > copy the old file to a new one, add to the new one, and then rename
 > > it.  Any processes that have the old one mapped will continue to use
 > > it.
 > 
 > Ah, I hadn't thought about that.  Probably because this happens during
 > installation, where the database was just created, so I wouldn't expect
 > any consumers yet.  But I see your point; this could be a problem for
 > deferred installations of certain eclipse packages.

The gcj-dbtool isn't just used by Eclipse.  It has to be safe when
adding a jar in a live system.

 > > The problem is that the Eclipse installer is doing things in a very
 > > inefficient way.  The most efficient way is to generate a separate map
 > > for each jar file, and then merge them all at the end.  This is very
 > > fast.  It also has the advantage that the resulting file is more
 > > compact.
 > 
 > 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.

Andrew.