You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexey Varlamov <al...@gmail.com> on 2006/06/10 09:42:30 UTC
[classlib] StringBuilder vs StringBuffer
Folks,
I've noticed that available implementation of j.l.StringBuilder
performs quite slowly, so j.l.StringBuffer outperforms it several
times despite of all synchronization. I filed corresponding JIRA
tracker, HARMONY-589.
Yet there is one issue which I'd like to raise here - code duplication
between these classes. AFAIU they are almost identical, except
synchronization and return types, -therefore will perfectly fit to a
common superclass.
BTW, RI goes exactly this way - one can look at official specification
of corresponding serialized forms to ascertain that, so there will be
no compartibility issues.
If noone objects, I volunteer to do this refactoring. Guess it does
not require any golden tickets :) Should I assign the JIRA issue to
myself? Or any other steps needed?
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] StringBuilder vs StringBuffer
Posted by Alexey Varlamov <al...@gmail.com>.
Nathan,
I've attached suggested fix to the JIRA issue. Seems that now we can
even beat the Reference Implementation on the microbenchmark ;)
No new test failures introduced, I assume this is enough to ensure
patch correctness.
2006/6/10, Nathan Beyer <nb...@kc.rr.com>:
> Go for it. Just work out your changes, create a patch and attach it to the
> issue you opened. In terms of passivity, one of the key implementation
> aspects to consider is that serialization works correctly for both classes
> afterwards.
>
> -Nathan
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [classlib] StringBuilder vs StringBuffer
Posted by Nathan Beyer <nb...@kc.rr.com>.
Go for it. Just work out your changes, create a patch and attach it to the
issue you opened. In terms of passivity, one of the key implementation
aspects to consider is that serialization works correctly for both classes
afterwards.
-Nathan
> -----Original Message-----
> From: Alexey Varlamov [mailto:alexey.v.varlamov@gmail.com]
> Sent: Saturday, June 10, 2006 2:43 AM
> To: harmony-dev@incubator.apache.org
> Subject: [classlib] StringBuilder vs StringBuffer
>
> Folks,
> I've noticed that available implementation of j.l.StringBuilder
> performs quite slowly, so j.l.StringBuffer outperforms it several
> times despite of all synchronization. I filed corresponding JIRA
> tracker, HARMONY-589.
>
> Yet there is one issue which I'd like to raise here - code duplication
> between these classes. AFAIU they are almost identical, except
> synchronization and return types, -therefore will perfectly fit to a
> common superclass.
> BTW, RI goes exactly this way - one can look at official specification
> of corresponding serialized forms to ascertain that, so there will be
> no compartibility issues.
>
> If noone objects, I volunteer to do this refactoring. Guess it does
> not require any golden tickets :) Should I assign the JIRA issue to
> myself? Or any other steps needed?
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org