JDK-4752992 : (cs) Looking up non-NIO charsets is very slow
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 1.4.1
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2002-09-25
  • Updated: 2003-02-04
  • Resolved: 2002-12-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other Other
1.4.0_04 04Fixed 1.4.1_03Fixed 1.4.2Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The performance of extended encoding gets too worse in 1.4.1

I attached the sample code.
It measures the performance under the following 3 cases.

case1 : Specify the ISO-8859-1 in OutputStreamWriter and call its constructor.
case2 : Specify the MS932 in OutputStreamWriter and call its constructor.
case3 : Specify the ISO-8859-1 and UTF-8 and execute in turn

We expect the performance will be as follows.
  - case2 will the same to case1 or a little bit more than case1
  - case3 will be double of case1

In 1.3.1_04, the performance seems to the above, but in 1.4.0_01 and
1.4.1fcs, case2 and case3 seems to be too worse.
(Unit is  [msec])

           1.3.1_04       1.4.0_01       1.4.1
-----------------------------------------------------
case1        9257           8393          8714
case2       10024         287180       1966813
case3       18471          27365         27187



1. Reproduce

   Compile  the attached sample code by each version and invoke
   goedel[32]%  java charsettest

2. configration

SunOS jpe 5.8 Generic_108528-06 sun4u sparc SUNW,Ultra-80 (dual)

3. Note
  - This is tested on Japanese locale and japanese locale is in the case2.
    So, that is the serious problem for Japanese user(or user using other
    extended locale)
  - case3 is problem. Under Japanese environment, the changing encoding
    often happens. The case3 is the very case.
    Japanese user need the improvement of performance(decreasing the 
    switching overhead)

2002-09-25
==============================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.0_04 1.4.1_03 mantis-beta FIXED IN: 1.4.0_04 1.4.1_03 mantis-beta INTEGRATED IN: 1.4.0_04 1.4.1_03 mantis-b11 mantis-beta
14-06-2004

PUBLIC COMMENTS I tried to reproduce the bug with 1.3.1_05, 1.4.0, 1.4.1 o my win2k 'COMPAQ' machine. Following are the numbers I got: ========================================================= | 1.3.1_05 | 1.4.0fcs | 141fcs ========================================================= Case 1.| 8452 | 6409 | 6420 Case 2.| 8883 | 41840 | 305218 Case 3.| 16964 | 14140 | 14181 ========================================================= Conclusions: 1) For 1.3.1_05 performance is as expected. 2) For 1.4.0fcs performance has decreased for 'case 2' only. 3) For 1.4.1fcs prformance has decreased for 'case 2' only. 4) As expected 'case 3' performance is approximately double of 'case 1' for all of these 3 JDK's. Also, performance with 1.4.0 and 1.4.1 is increased (less numbers) as compared with 1.3.1_05 with 'case 3'. SO, the problem is only with 'case 2' i.e. performance has decreased for MS932 only. ###@###.### 2002-10-11
11-10-2002

SUGGESTED FIX Please see http://nio.sfbay/rev/4752992 for the fix that will be implemented in Mantis. For convenience I've also attached a tar file of that webrev to this bug report. -- ###@###.### 2002/11/21
11-10-0187

EVALUATION Yes, it is. Will fix in Mantis (1.4.2) and in relevant patch releases. -- ###@###.### 2002/11/21
11-10-0187