JDK-6411870 : REGRESSION: Loading certain png images 25x slower than 1.5
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-04-11
  • Updated: 2011-01-28
  • Resolved: 2006-04-19
Related Reports
Duplicate :  
JDK-6409506 - On b78 it takes 10 times longer to read a compressed binary file
Relates :  
JDK-6412741 - BufferedInputStream.read1() contains possibly neverending loop
Description
Compile the attached test case and run it. It loads two different images with ImageIO and MediaTracker.
On 1.5, for the second time through, I get a time of ~40ms with ImageIO and ~70ms with MediaTracker. On 1.6 I get ~1100 for each!
Comments
EVALUATION It seems that degradation was introduced in b78: bash-2.05$ /java/jdk/bin/jver 6.0-b77 java IOTest ImageIO load time of eyes1.dup.png=1121 MediaTracker load time of eyes1.dup.png=1488 ImageIO load time of eyes1.png=37 MediaTracker load time of eyes1.png=195 ImageIO load time of eyes1.dup.png=43 MediaTracker load time of eyes1.dup.png=1 ImageIO load time of eyes1.png=25 MediaTracker load time of eyes1.png=0 ImageIO load time of eyes1.dup.png=18 MediaTracker load time of eyes1.dup.png=0 ImageIO load time of eyes1.png=29 MediaTracker load time of eyes1.png=0 bash-2.05$ /java/jdk/bin/jver 6.0-b78 java IOTest ImageIO load time of eyes1.dup.png=4016 MediaTracker load time of eyes1.dup.png=4571 ImageIO load time of eyes1.png=3614 MediaTracker load time of eyes1.png=3589 ImageIO load time of eyes1.dup.png=3660 MediaTracker load time of eyes1.dup.png=3678 ImageIO load time of eyes1.png=3431 MediaTracker load time of eyes1.png=3504 ImageIO load time of eyes1.dup.png=3586 MediaTracker load time of eyes1.dup.png=3693 ImageIO load time of eyes1.png=3398 MediaTracker load time of eyes1.png=3636 And there was no 2D related changed in b78. Profiler shows that significant part of time is spent in method java.io.BufferedInputStream.fill() (about 96%) and inside it in the java.util.zip.InflaterInputStream.read(byte[], int, int) (about 58%) (note that in b77 java.io.BufferedInputStream.fill() takes only 7%). Probably one of these following fixes is related to this problem: 6192696 - BufferedInputStream.read(byte[], int, int) can block if the entire buffer can't be filled 6364346 - GZIPOutputStream is slower on 1.4.2_11-b02 than on 1.4.2_09 Reassigning to classes_io for further investigation.
12-04-2006