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 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 wrote:
> >
> > On 14 January 2008 at 16:21, Tim Ellison 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
>