<br><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 09:31, Ulf Zibis <span dir="ltr"><<a href="mailto:Ulf.Zibis@gmx.de">Ulf.Zibis@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Martin, thanks for taking the time.<br>
<br>
Am 26.06.2009 15:53, Martin Buchholz schrieb:
<blockquote type="cite"><br>
<br>
<div class="gmail_quote"><div class="im">On Fri, Jun 26, 2009 at 01:37, Ulf Zibis <span dir="ltr"><<a href="mailto:Ulf.Zibis@gmx.de" target="_blank">Ulf.Zibis@gmx.de</a>></span>
wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">1.
Hopefully some volunteer would be found to fix <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737" target="_blank">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737</a><br>
before JDK7 API-freeze.<br>
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.</blockquote>
<div><br>
The way to motivate us around here <br>
is to provide the prototype implementation that<br>
demonstrates the speedup.<br>
</div>
</div></div>
</blockquote>
<br>
Sorry, I'm not the specialist on how to provide NIO buffers from native
memory, and first, I will finish my work on charsets.<br>
<br>
Motivation:<br>
Xueming states:<br>
<b><tt>"dat" based uses less
disk space, but it has larger startup time, reading an additional "big"
dat file during class loading/initializing actually takes much
longer time than I expected (I hit the extreme when I worked on the
EUC_TW, which I make the size only 30% of the existing
one, but startup is a disaster regression, ...<br>
</tt></b></div></blockquote><div><br>I'm surprised. I would expect startup to actually be faster.<br>I assume we're only reading the bytes that are necessary<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><br>
If loading x bytes from dat file via getResourceAsStream() takes much
longer time than loading x+30% bytes from class file, processing the
UTF-8 conversion, instantiating and initializing additional Class
objects, I imperatively presume, that there must be a big chance for
significantly improving read speed from uncompressed jar file (here
charsets.jar), by using direct channels or how ever. I presume,
enhancing reading from jar files would be a big fish in performance
gain for the whole JDK, as it is very common task in JVM's daily work.<div class="im"><br>
<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
While benchmarking, I discovered to my horror that the simple<br>
<br>
jar cf /tmp/t1 ...<br>
jar i /tmp/t1<br>
<br>
fails, because it tries to create the replacement jar in "." and then<br>
rename() it into place. Oops... Better refactor out the code that<br>
puts the replacement temp file in the same directory.<br>
Better write some tests for that, too.<br>
</blockquote>
<br>
</div>
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.<br>
It blows up the code, and following the code demands annoying scrolling.<br>
Better add additional comment to original code.<br>
</blockquote>
<div><br>
The original code created temp files in *two* places, <br>
and did it differently.<br>
</div>
</div>
</blockquote>
<br></div>
Oops, at my first search on your code I only found *one* usage of
createTempFileInSameDirectoryAs(). Did you add the 2nd later?<br>
But there is only one usage of directoryOf(). Shouldn't you inline this?<div class="im"><br>
</div></div></blockquote><div><br>This is modern software engineering. <br>We are all encouraged to write many small methods.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="im"><br>
<blockquote type="cite">
<div class="gmail_quote">
<div>
<pre><span>I think the name
createTempFileInSameDirectoryAs
makes the current code much clearer.
</span></pre>
</div>
</div>
</blockquote>
<br></div>
Yes, this is pretty clear, but the cost is 19 lines against 2+2 plus
demanding the reader for annoying scrolling.<br>
Thinking about directoryOf() I guess, following this strategy you would
find ten's of locations in Main.java where you could refactor out code
into small well self-explaining methods, but wouldn't this end up in a
mess of unreadable blown-up code?<div class="im"><br>
</div></div></blockquote><div><br>Find suitable abstractions and refactor them into a separate piece of code.<br><br>The win is a lot bigger if you make the new abstractions <br>public supported parts of the API,<br>but that is harder with the JDK.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><div class="im"><br>
<blockquote type="cite">
<div class="gmail_quote">
<div>
<pre><span>
</span></pre>
Also, JITs tend to be very good at inlining.<br>
</div>
</div>
</blockquote>
<br></div>
(... after some loops), yes, I know<div class="im"><br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
3. What happens, if original file is exactly named "jartmp"<br>
I think you would better add ".tmp" at the end of the filename, and
remove it later.<br>
Does your new code work with? :<br>
jar cf /jartmp/t1 ...<br>
jar i /jartmp/t1<br>
<font color="#888888"></font></blockquote>
<div><br>
File.createTempFile doesn't literally create a file named jartmp.<br>
That's only the prefix. And it promises to return <br>
a freshly created empty file.<br>
</div>
</div>
</blockquote>
<br></div>
Now I understand deeper. I just wondered why in fact just renaming
"tmp" to "jartmp" would resolve your bug. I didn't recognize the 2nd
location, where wrong "." was used for dir name.<br>
</div></blockquote><div><br>The renaming jar -> jartmp is not significant.<br><br>Martin<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><br>
-Ulf<br>
<br>
</div>
</blockquote></div><br>