Andrei,
That would be great to see a standardized set of closes for the custom streams (as well as a specified order of closure). I'm going to have to disagree with both you and Noel on the severity and performance impact of string concatenation. HotSpot or not, the performance penalty for that type of code is immense (especially in some of the looped retrieves from the POP3 server). An excellent (if slightly dated) reference on the topic is Jack Shirazi's "Java Performance Tuning". --Peter -----Original Message----- From: Andrei Ivanov [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 28, 2002 1:29 PM To: James Developers List Subject: Re: [Bug 11235] Extensive use of string concatenation throughout code base Hi, Noel, it is very nice to hear at last about good habits and especially in relation to handlers. Your points about stings concatenation and corresponding performance impact is a very good one, but it is not as serious this moment (when we have HotSpot :-) ) as how various streams are created and closed in, for example, SMTPHandler. SMTPHandler utilizes a number of "custom" streams and also uses several streams from java.io. I can bet that not many of current James developers can clearly say which stream is created at which moment, and what is the order of closing of streams (if there should be one :-) ). I can state that there is no such order in SMTPHandler (not every custom steam implements close() method so that underlying steam will be never closed which is not very good...). I can provide fixed SMTPHandler (since I ve been working a lot with this part of James for my project) so that other handlers can be fixed as well similar way. How does this sound? Best regards, Andrei ----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> Sent: Sunday, July 28, 2002 10:51 PM Subject: [Bug 11235] Extensive use of string concatenation throughout code base > re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11235 > > "This bug is really a performance/scalability/resources issue. The code is > full (especially in the handlers) of string concatenation operators. This > is > a very resource intensive operation when concatenating anything more than 2 > string (i.e. "a" + "b" + "c" + "d") because of the temporary objects created > and then discarded with each concatenation. It is very preferable to use a > single StringBuffer instance to do this type of concatenation. This > eliminates the temporary object creation and hence improves performance. > This > is especially critical in the assorted handlers, where the use of the > concatenation operator is most prevalent, because these classes are going to > be your bottlenecks for client interaction." > > I suppose that this would be a good project for people who want to help out > without getting too deep into intricacies. Not the highest of priorities, > but the changes should be clear and isolated. The patches should be fairly > easy for people to vet, and the maintainers to commit. > > Peter, do you want to pick a single file, make the changes, and post it as a > sample for what you think others should do? Not that this is more than rote > conversion, but we might as use something as simple as this to start trying > to adopt good habits. > > --- Noel > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
