hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Gl├╝ck <...@odi.ch>
Subject Re: Performance tuning
Date Fri, 26 Oct 2007 14:54:26 GMT
Pascal S. de Kloe wrote:
> You made your point clear: find the problem and eliminate it.
> However performance isn't that black and white. The thing is that every resource
> spend on org.apache.http.** is too much. They asked me if we can improve things
> and I think we can.
> Yes, synchronized methods *do* slow things down. Yes, creating unnecessary
> objects for each connection is bad.
> This HttpState was simply the first class out of a random pick to test the
> willingness to improve on the performance subject. It took me a few minutes to
> write...

I agree that perfomance is the sum of many things. So fixing many small
things does add up. Still you better start with the ones that give you
the most benefits. So I suggest to use a profiler to identify the places
where the most time is spent (I dare to doubt it's synchronization and
class casts) and which objects are collected the most. Then tackle
these. A "random pick" is hardly the best. Feel free to send us profiler
data (screenshots may suffice) to backup your patches or if you need
advice with their interpretation.

I do support your effort to review and improve the HttpClient code base
in this respect. At the same time I would like you to focus on the most
severe time/memory wasters. I have no interest in sacrificing code
clarity for ├╝bertuning for instance. I would also like to point out that
the 3.x code base is virtually end of life. That means that patches have
the greatest chance of being accepted if they are minimally intrusive.


To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

View raw message