Other | Other | Other |
---|---|---|
1.4.0_04 04Fixed | 1.4.1_03Fixed | 1.4.2Fixed |
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
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 ==============================================================================
|