<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Martin, thanks for taking the time.<br>
<br>
Am 26.06.2009 15:53, Martin Buchholz schrieb:
<blockquote
cite="mid:1ccfd1c10906260653j2f91a7ffx4a3056d67129f6a0@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Fri, Jun 26, 2009 at 01:37, Ulf Zibis <span
dir="ltr"><<a moz-do-not-send="true" 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;">1.
Hopefully some volunteer would be found to fix <a
moz-do-not-send="true"
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>
</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><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.<br>
<br>
<br>
<blockquote
cite="mid:1ccfd1c10906260653j2f91a7ffx4a3056d67129f6a0@mail.gmail.com"
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 class="im"><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>
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?<br>
<br>
<blockquote
cite="mid:1ccfd1c10906260653j2f91a7ffx4a3056d67129f6a0@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
<pre><span class="new">I think the name
createTempFileInSameDirectoryAs
makes the current code much clearer.
</span></pre>
</div>
</div>
</blockquote>
<br>
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?<br>
<br>
<blockquote
cite="mid:1ccfd1c10906260653j2f91a7ffx4a3056d67129f6a0@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
<pre><span class="new">
</span></pre>
Also, JITs tend to be very good at inlining.<br>
</div>
</div>
</blockquote>
<br>
(... after some loops), yes, I know<br>
<br>
<blockquote
cite="mid:1ccfd1c10906260653j2f91a7ffx4a3056d67129f6a0@mail.gmail.com"
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>
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>
<br>
-Ulf<br>
<br>
</body>
</html>