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

[Ziga Mahkovec]

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 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.

-- 
Ziga