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 Tue, 15 Jan 2008 10:52:31 GMT
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

View raw message