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. Ortwin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
