You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Ortwin Glück <od...@odi.ch> on 2005/12/05 09:43:01 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/
Oleg,
Is it really worth implementing your own number parsing? I don't think
Integer.parseInt will kill us, honestly.
Odi
olegk@apache.org wrote:
> Provided a utility class to parse unsigned integers from a char array
> buffer without creating intermediate objects (garbage)
---------------------------------------------------------------------
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
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 Oleg Kalnichevski <ol...@apache.org>.
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 Oleg Kalnichevski <ol...@apache.org>.
On Mon, Dec 05, 2005 at 10:33:50AM +0100, Ortwin Gl?ck wrote:
> 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
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,
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
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
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 Oleg Kalnichevski <ol...@apache.org>.
On Mon, Dec 05, 2005 at 09:43:01AM +0100, Ortwin Gl??ck wrote:
> Oleg,
>
> Is it really worth implementing your own number parsing? I don't think
> Integer.parseInt will kill us, honestly.
>
> Odi
>
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
> olegk@apache.org wrote:
> >Provided a utility class to parse unsigned integers from a char array
> >buffer without creating intermediate objects (garbage)
>
>
> ---------------------------------------------------------------------
> 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