On Fri, Jun 26, 2009 at 01:37, Ulf Zibis <ulf.zi...@gmx.de> wrote: > Am 26.06.2009 02:57, Martin Buchholz schrieb: > >> I did some benchmarking, >> and found that my changes "only" make jar 10-20% faster. >> Disappointing - we expect an order of magnitude for every commit! >> > > 1. Hopefully some volunteer would be found to fix > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737 > before JDK7 API-freeze. > Especially, if jar is not compressed, as in case of normal JDK > installation, reading entries from jar should be much faster through > java.nio.channels, than via BuffererdInputStream. >
The way to motivate us around here is to provide the prototype implementation that demonstrates the speedup. > > > >> While benchmarking, I discovered to my horror that the simple >> >> jar cf /tmp/t1 ... >> jar i /tmp/t1 >> >> fails, because it tries to create the replacement jar in "." and then >> rename() it into place. Oops... Better refactor out the code that >> puts the replacement temp file in the same directory. >> Better write some tests for that, too. >> > > 2. I don't like to refactor out the code in case of only once used, and > only to better "comment" what the 2 lines are doing. > It blows up the code, and following the code demands annoying scrolling. > Better add additional comment to original code. > The original code created temp files in *two* places, and did it differently. I think the name createTempFileInSameDirectoryAs makes the current code much clearer. Also, JITs tend to be very good at inlining. > > 3. What happens, if original file is exactly named "jartmp" > I think you would better add ".tmp" at the end of the filename, and remove > it later. > Does your new code work with? : > jar cf /jartmp/t1 ... > jar i /jartmp/t1 > File.createTempFile doesn't literally create a file named jartmp. That's only the prefix. And it promises to return a freshly created empty file. Martin > -Ulf > > > >
