| 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
==============================================================================
|