Hello, I have two questions related to performance degradation synopsis. > I suggest the following as a result... > 2. File all the found issues to ICU database. I have looked through JIRAs and did not find a reproducer. Do we have one?
> useDaylightTime How this method might cause server benchmark degradation? Who calls this method frequently? May be we should change the caller either it is a part of the spec or our implementation? Thanks! On Nov 16, 2007 7:29 PM, Alexey Petrenko <[EMAIL PROTECTED]> wrote: > To be clear all these issues are not from migrating from previous > version of ICU to 3.8. But from removing Harmony code which duplicates > ICU code. > So we actually need to fix ICU not Harmony to get our performance and > other behaviors back. And the problem here could be that we are not > ICU and we do not have ICU committers, at least as far as I know. Thus > we can not be sure that needed patches will be integrated ASAP even if > we will create all needed patches our selves. > > Moreover some patches can contradict with ICU vision. For example > HARMONY-5085. The problem there that the Harmony method starts to > return array of ICU classes instead of array of Harmony J2SE public > API classes. Array scanning with ICU -> Harmony classes conversion > will degrade performance. So the only way here to fix ICU to return > public api classes instead of ICU classes. And I'm not sure that ICU > project will be ready to integrate such a changes. > > From the other hand I agree that we do not want to reinvent the wheel > and keep and support all this internationalization stuff in Harmony if > we can delegate it to another suitable project. But this project need > to fit Harmony needs :) > > I suggest the following as a result... > 1. Revert the patch which removes Harmony code which duplicates ICU. > 2. File all the found issues to ICU database. > 3. Create as much patches for ICU to fit Harmony needs as we can and > provide them to ICU. > 4. Wait until all these patches will be integrated and new ICU release come. > 5. Remove ICU duplicating functionality again. > > Thoughts? Objections? > > Thanks in advance. > > SY, Alexey > > 2007/11/16, Sergey Kuksenko <[EMAIL PROTECTED]>: > > > Hi All, > > > > I'd like to continue discussion about migration to new ICU which was done by > > r592434 & r593469 commits. > > This migration is a big deal and it should be done in any case. > > However, after migration we got a set of problems like a set of failures and > > performance degradations. > > Some of the failures were already fixed, some of them are noticed on > > http://wiki.apache.org/harmony/MigrateToICU ,some of them are noticed in > > JIRA like (https://issues.apache.org/jira/browse/HARMONY-5085) and I am > > afraid that some of them are not yet detected. > > Performance degradation you can see in JIRAs ( > > https://issues.apache.org/jira/browse/HARMONY-5129 & > > https://issues.apache.org/jira/browse/HARMONY-5122) > > In general we may conclude that performance of SPECjbb2005 with DRLVM > > decreased by 20%. > > Moreover, according our results, performance of application servers measured > > with EAStress degraded 3x times!!! > > Also, there are a lot of small tests which can show degradation. > > > > And the key problem here that we have no so much time before code freeze in > > December and it is not good to have new milestone release worse then > > previous. > > *I suggest to roll back ICU migration till the end of current milestone.* > > Let's apply these patches exactly after beginning of the next milestone and > > will work on all stability and performance problems together in next > > milestone. I hope in that case we will have more time and tune new ICU more > > efficiently. > > > > > > -- > > Best regards, > > --- > > Sergey Kuksenko. > > Intel Enterprise Solutions Software Division. > > > -- With best regards, Alexei, ESSD, Intel
