harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Qiu" <sean.xx....@gmail.com>
Subject Re: [classlib]remove the duplicate locale data
Date Wed, 30 Jan 2008 09:05:34 GMT
Hi, Tony

I volunteered to fix some of the differences for you, if you are busy.

Best regards.


2008/1/28, Tony Wu <wuyuehao@gmail.com>:
>
> Ok, investigating.
>
> On 1/28/08, Rustem Rafikov <r.v.rafikov@gmail.com> wrote:
> > Hi Tony,
> >
> > Please look at another issue connected with the ICU commit.
> > https://issues.apache.org/jira/browse/HARMONY-5435
> > It has not been investigated deeply yet.
> >
> > --Rustem
> >
> >
> > On Jan 28, 2008 6:49 AM, Tony Wu <wuyuehao@gmail.com> wrote:
> >
> > > They are all caused by different implementation of DateFormat, which
> > > I've recorded on wiki. I think they are acceptable unless it breaks
> > > some real product.  See following output, they have the same meaning
> > > but don't exactly equal on text.
> > >
> > > Result:   'text here 12:17:01 PM GMT+00:00 and here'
> > > Expected: 'text here 12:17:01 UTC PM and here'
> > >
> > > Result:   'text here 3:16:03 PM GMT+00:00 and here'
> > > Expected: 'text here 3:16:03 o'clock PM UTC and here'
> > >
> > > Result:   'text here 00-04-05 and here'
> > > Expected: 'text here 05/04/00 and here'
> > >
> > > I'll open another thread to ask people's opinions on this difference.
> > >
> > > On 1/25/08, Andrey Pavlenko <andrey.a.pavlenko@googlemail.com> wrote:
> > > > Tony,
> > > >
> > > > It looks like this commit caused a regression. Could you take a look
> at
> > > > HARMONY-5430, please?
> > > >
> > > > 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
> > >
> >
>
>
> --
> Tony Wu
> China Software Development Lab, IBM
>



-- 
Sean Qiu
http://xiaoxia.turendui.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message