You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2006/03/28 23:08:32 UTC
Re: svn commit: r353848 - in
/jakarta/httpcomponents/trunk/http-core/src: java/org/apache/http/
java/org/apache/http/io/ java/org/apache/http/util/
test/org/apache/http/util/
Odi et al,
I rolled back the changes and reverted to standard Integer#parseInt for
parsing numbers in HTTP messages
Oleg
On Mon, 2005-12-05 at 10:39 +0100, Oleg Kalnichevski wrote:
> On Mon, Dec 05, 2005 at 10:33:50AM +0100, Ortwin Gl?ck wr
>
> ote:
> > Oleg,
> >
> > All right. I am glad you are not doing this unconciously. It will be
> > interesting to see benchmark results. My guess is that you should not
> > see a significant performance gain (I expect less than 5%). The modern
> > GC algorithms in the Sun VMs are very good for short-lived Objects. To
> > see a difference you probably have to run HttpClient with multiple
> > threads under a high load for a long time, so that enough garbage is
> > produced and the GC actually has to run. The number of CPUs will have an
> > effect as well.
> >
> > Odi
> >
>
> Odi,
> I am planning to write a report on the code refactoring I have done in
> the past two weeks. Anyways, those changes were not made completely out
> of the blue. However, I do admit some of them can be seen as
> controversial. Give me some time to write it all up and and let us talk
> things over
>
> Oleg
>
> > Oleg Kalnichevski wrote:
> > >Odi,
> > >
> > >I am aware this is a questionable decision. The primary motivating
> > >factor was to implement zero (or almost zero) garbage HTTP request
> > >parsing and see if that results in any significant performance gains.
> > >
> > >I have run a few tests yesterday and so far the impact of reduced
> > >generation of intermediate objects when parsing HTTP requests seems
> > >minimal for JRE 1.5. So, I am fully prepared to revert this change if
> > >there are no tangble performance gains for older JREs. I would like
> > >to experiment a little further before such a decision is made
> > >
> > >Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: svn commit: r353848 - in /jakarta/httpcomponents/trunk/http-core/src:
java/org/apache/http/ java/org/apache/http/io/ java/org/apache/http/util/
test/org/apache/http/util/
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> Odi et al,
>
> I rolled back the changes and reverted to standard Integer#parseInt for
> parsing numbers in HTTP messages
>
> Oleg
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org