harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: Problems with migration to new ICU, r592434 & r593469
Date Sun, 18 Nov 2007 09:07:55 GMT
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?


On Nov 16, 2007 7:29 PM, Alexey Petrenko <alexey.a.petrenko@gmail.com> 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 <sergey.kuksenko@gmail.com>:
> > 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,
ESSD, Intel

View raw message