But remember, the my interest in this discussion is not class loading
speed, it's resource file loading speed. ;-)
-Ulf
Am 18.05.2009 22:21, Xueming Shen schrieb:
Performance of Inflater/Deflater does not change the class loading
performance from
jar files bundled with JDK/JRE, they have be
Clemens, Sherman,
you are right. Oops!
But there is another bottleneck, where both are concerned from:
If used by ZipFile#getInputStream(ZipEntry entry), the underlying
BufferedInputStream is very slow because of internal copying.
I'm sure, direct ByteBuffer, served from getChannel(ZipEntry ent
Clemens,
If I read the code correctly, what your patch is trying to address is to
save the redundant
memory allocate/free operations at native level, if the input byte
buffer is bigger than the
"stride" size? In other words, it does not really reduce any memory copy
but reduce the
trip numbers
Performance of Inflater/Deflater does not change the class loading
performance from
jar files bundled with JDK/JRE, they have been "uncompressed" after
installation...
Sherman
Ulf Zibis wrote:
Am 04.05.2009 23:38, Martin Buchholz schrieb:
I think many people will be interested in performan
Hi Ulf,
I don't think the JVM uses the Inflater/Deflater classes directly, but
instead accesses zblib directly - but I could be wrong.
Furthermore as far as I know charsets.jar isn't compressed.
The patches only try to remove some horrible memcpy overhead in some
common situation.
- Clemens
200
Am 04.05.2009 23:38, Martin Buchholz schrieb:
I think many people will be interested in performance improvements
in Inflater/Deflater. I may have time to help review.
Yes, there is also interest from charset de/encoding side. See:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818736
h
Hi Martin,
> I think many people will be interested in performance improvements
> in Inflater/Deflater. I may have time to help review.
>
> Caution: This is an area where it can be very tricky to make
> improvements. Past efforts have optimized one usage pattern
> at the cost of pessimizing anot
I think many people will be interested in performance improvements
in Inflater/Deflater. I may have time to help review.
Caution: This is an area where it can be very tricky to make
improvements. Past efforts have optimized one usage pattern
at the cost of pessimizing another.
Martin
On Mon, M
Clemens, I will be the "contact person" for this change. I will take a
look at you patch
this week.
Thanks,
Sherman
Clemens Eisserer wrote:
Hi,
I've written some patches for Inflater/Deflater about a year ago with
Dave Bristor as contact point, however I was in hurry and suspended
work on it
Hi,
I've written some patches for Inflater/Deflater about a year ago with
Dave Bristor as contact point, however I was in hurry and suspended
work on it back then.
I would be happy if somebody could have a look at:
https://bugs.openjdk.java.net/show_bug.cgi?id=19
... the sooner the stuff is
10 matches
Mail list logo