Hi, Tony I volunteered to fix some of the differences for you, if you are busy.
Best regards. 2008/1/28, Tony Wu <[EMAIL PROTECTED]>: > > Ok, investigating. > > On 1/28/08, Rustem Rafikov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > On 14 January 2008 at 16:21, Tim Ellison < > [EMAIL PROTECTED]> > > > > > 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
