On Mar 24, 2009, at 3:40 AM, Rene Zaumseil wrote: > Hi, > > using larger binary files takes some time in fossil. > The first commit is really fast. After that, the time is spent > in function content_deltify().
The issue here was that the delta generator was inefficient when given two large files that had very few similarities. That inefficiency has now been addressed and the latest fossil check-in runs 50 to 100 times faster on the test files. Since this is an obscure problem, I did not regenerate precompiled binaries. This problem only comes up with checking in a new version of a file that is both large and which is completely different from the prior version. In the case in question, the file was a compressed tarball. Because of the compression, any minor change to the tarball resulted in a file that was completely different. This is a very unusual case. But fossil now handles it as efficiently as the common case of similar files. Note that fossil will work fine (now) with compressed files in the archive. But you will get much better delta compression if you leave the files uncompressed. In the case here, the overall repository would be smaller if the tarballs were stored uncompressed. D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
