harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [classlib]remove the duplicate locale data
Date Sun, 10 Feb 2008 05:07:11 GMT
On 2/10/08, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Good work Tony.  Perhaps a wiki page or umbrella JIRA would help us
> track these?  I think they may get lost in mail discussion.

That's right. Update to wiki page
http://wiki.apache.org/harmony/MigrateToICU

>
> Just my 2c.
> Tim
>
> Tony Wu wrote:
> > On 2/7/08, Pavel Pervov <pmcfirst@gmail.com> wrote:
> >> Tony,
> >>
> >> Unfortunately, I have a number of JIRAs for you. They all are
> >> regressions after removing duplicate locale data.
> >>
> >> Here they go:
> >>
> > Hi, Pavel and all
> > my solution below
> >
> >> https://issues.apache.org/jira/browse/HARMONY-5459
> > Fixed, thanks for your patch.
> >> https://issues.apache.org/jira/browse/HARMONY-5461
> > Can not reproduce
> >> https://issues.apache.org/jira/browse/HARMONY-5465
> > Reported to ICU before. ICU refused to fix but we can work around it
> > if necessary. Need your suggestion.
> >> https://issues.apache.org/jira/browse/HARMONY-5466
> > non-bug difference, due to CLDR data.
> >> https://issues.apache.org/jira/browse/HARMONY-5467
> > non-bug difference, due to CLDR data.
> >> https://issues.apache.org/jira/browse/HARMONY-5468
> > report to http://bugs.icu-project.org/trac/ticket/6174
> >> https://issues.apache.org/jira/browse/HARMONY-5469
> > I suppose it is another CLDR data difference, need your commets.
> >
> >
> >> I would like to know your opinion on whether they should be fixed of
> >> resolved some other way.
> >>
> >> Thanks,
> >>    Pavel.
> >>
> >> P.S. There is also HARMONY-5013 which was introduced with moving to
> >> ICU4J 3.8. Could you, please, look at that issue too?
> >>
> >> On 1/23/08, Tony Wu <wuyuehao@gmail.com> wrote:
> >>> Thanks very much, so we got 4MB src code cutted w/o pay. Cheer!
> >>>
> >>> On 1/23/08, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> >>>> Hi Tony,
> >>>>
> >>>> The good thing is, after the commit I have compared revisions 610727
> >>>> (before your commit) and 612866 (after your commit) and haven't
> >>>> noticed degradation while running SPECjbb2005 in 2-VM configuration.
> >>>> That's definitely good news :)
> >>>>
> >>>> Thanks,
> >>>> Aleksey.
> >>>>
> >>>> On Jan 21, 2008 10:17 AM, Tony Wu <wuyuehao@gmail.com> wrote:
> >>>>> Thanks, Aleksey and all
> >>>>>
> >>>>> patch committed at r612718. Then I'm going to deal with the non-bug
> >>>>> difference. Hopefully many legcy bugs/differences can be fixed this
> >>>>> time.
> >>>>>
> >>>>>
> >>>>> On 1/17/08, Aleksey Shipilev <aleksey.shipilev@gmail.com>
wrote:
> >>>>>> Hi, guys!
> >>>>>>
> >>>>>> Sure, correctness is important, but performance is important
too. I
> >>>>>> had profiled both versions (clean and patched) and see no significant
> >>>>>> difference there: there are more GC happens what I believe connected
> >>>>>> to internal ICU object creation and such. So, there are no obvious
way
> >>>>>> to maintain the same performance level, and may be we will try
again
> >>>>>> to eliminate ICU usage from the hotpath of frequently used workloads
-
> >>>>>> but previous investigation shows it's not that simple.
> >>>>>>
> >>>>>> Tony, please go ahead with committing this patch, we will deal
with
> >>>>>> ICU performance issues a little later.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Aleksey.
> >>>>>>
> >>>>>> On Jan 15, 2008 1:52 PM, Tony Wu <wuyuehao@gmail.com>
wrote:
> >>>>>>> Hi Aleksey,
> >>>>>>>
> >>>>>>> Thanks for you help.
> >>>>>>>
> >>>>>>> I've proved there is no performance degradation on my machine
> >>>>>>> mentioned in my previous mail. I suppose the different result
on your
> >>>>>>> machine is caused by different options to SpecJBB. Anyway,
my POV is
> >>>>>>> that we should be willing to pay for the adoption of ICU
if we have
> >>>>>>> to. All of us should be positive on this point. I'd like
to clarify
> >>>>>>> the factors I'm facing below.
> >>>>>>>
> >>>>>>> Firstly, the original implementation of harmony is faster
but
> >>>>>>> incorrect. It is not reasonable to keep the code as is and
refuse to
> >>>>>>> correct it just because the bad version has better performance.
IMHO
> >>>>>>> performance is nothing if there is no correctness.
> >>>>>>>
> >>>>>>> Secondly, we adopt ICU through delegation which involves
extra method
> >>>>>>> calls than we implement it by ourselves, it does harm to
performance
> >>>>>>> and can not be worked around. But please do not forget we
benefit from
> >>>>>>> ICU in bug fixing, maintenance, smaller code size and so
on.
> >>>>>>>
> >>>>>>> Lastly, branching does not make sense to me. My fix is very
separate
> >>>>>>> in luni and text, I can not guarantee that there is no modification
> >>>>>>> during my work, so the synchronization between HEAD and
my branch is
> >>>>>>> required. Actually only I myself am working on the development
work
> >>>>>>> (Surely, Aleksey is very helpful on testing), this synchronization
> >>>>>>> might be a nightmare to me. Furthermore, the code on branch
will not
> >>>>>>> be automatically tested by continuous integration system
and BTI, I do
> >>>>>>> not want to work without collaboration, that's not an open
source
> >>>>>>> style, right? Will you ask a contributor to create a branch
and play
> >>>>>>> with himself whenever he wants to contribute?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 1/15/08, Mark Hindess <mark.hindess@googlemail.com>
wrote:
> >>>>>>>> On 14 January 2008 at 16:21, Tim Ellison <t.p.ellison@gmail.com>
wrote:
> >>>>>>>>> Aleksey Shipilev wrote:
> >>>>>>>>>> Yep, Tim, you're right. I believe that new implementation
fixes a
> >>>>>>>>>> number of bugs and will try to get it not degrading.
I just want to
> >>>>>>>>>> maintain the performance level of current trunk
on the same level,
> >>>>>>>>>> gradually fixing functional bugs. I don't like
to sacrifice
> >>>>>>>>>> performance of HEAD revision for non-critical
bugfix. That is, I want
> >>>>>>>>>> to see HEAD changes like this:
> >>>>>>>>>>
> >>>>>>>>>> "high performance, minor bug -> high performance,
no bugs"
> >>>>>>>>>>
> >>>>>>>>>> rather than
> >>>>>>>>>>
> >>>>>>>>>> "high performance, minor bug -> low performance,
no bugs -> high
> >>>>>>>>>> performance, no bugs"
> >>>>>>>>>>
> >>>>>>>>>> ...because anyone could get the HEAD Harmony
revision for
> >>>>>>>>>> performance measurements at any time.
> >>>>>>>> Couldn't someone also get the HEAD Harmony revision
and suffer from the
> >>>>>>>> known/fixable-with-Tony's-patch bugs at any time?
> >>>>>>>>
> >>>>>>>>>> What do you think?
> >>>>>>>>> For sure, improving performance and fixing the bugs
is the most
> >>>>>>>>> desirable state.  I actually don't mind some minor
performance
> >>>>>>>>> regression on HEAD between releases provided it
is an area being
> >>>>>>>>> actively worked upon.
> >>>>>>>> +1 especially if it fixes bugs
> >>>>>>>>
> >>>>>>>>> I'd also like to get to 4.2Mb source code reduction
too ;-)
> >>>>>>>> Me too.
> >>>>>>>>
> >>>>>>>>> If you and Tony are happy to work on the patch to
get it perfect then
> >>>>>>>>> go ahead.  I hope it is not too troublesome to keep
it in synch.  You
> >>>>>>>>> could also consider a branch in SVN.
> >>>>>>>> This bothers me too.  Firstly, while it is being developed
in patch
> >>>>>>>> on JIRA, it is likely only Tony and Aleksey will really
look at it.
> >>>>>>>> Secondly, that progress will be slow because of the
cost of keeping in
> >>>>>>>> sync - this applies to an SVN branch too.
> >>>>>>>>
> >>>>>>>> I can't help thinking we'll make more progress if we
apply the patch to
> >>>>>>>> HEAD now.  We'll get wider visibility of problems with
the new code -
> >>>>>>>> and there are likely issues beyond the performance problems
that have
> >>>>>>>> been the focus so far - and more people will see the
benefit of Tony
> >>>>>>>> (and Aleksey's) hard work in getting us to this point.
> >>>>>>>>
> >>>>>>>> I certainly don't want all this work to be completed
outside svn HEAD
> >>>>>>>> and committed a week or two before the freeze for next
milestone.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>  Mark.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Tony Wu
> >>>>>>> China Software Development Lab, IBM
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Tony Wu
> >>>>> China Software Development Lab, IBM
> >>>>>
> >>>
> >>> --
> >>> Tony Wu
> >>> China Software Development Lab, IBM
> >>>
> >>
> >> --
> >> Pavel Pervov,
> >> Intel Enterprise Solutions Software Division
> >>
> >
> >
>


-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message