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