<snip> Maybe now thats been done there should be a policy of only developing against "release" versions of commons code. </snip>
+1 This seems pretty sensible to me. Id suggest the committers seriously consider this idea. -----Original Message----- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Monday, 16 February 2004 08:58 To: Struts Developers List Subject: Re: string concatenation I agree. I seem to recall there were problems releasing Struts 1.1 because of a hold up getting a commons component released that struts was depending on. That was understandable as various bits of struts were being moved over to commons at the time. Maybe now thats been done there should be a policy of only developing against "release" versions of commons code. That way commons doesn't become something Struts has to wait on and its being developed against stable fully tested commons components. Niall ----- Original Message ----- From: "Hablutzel, Robert" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]>; "Struts Developers List" <[EMAIL PROTECTED]> Sent: Monday, February 16, 2004 12:32 AM Subject: RE: string concatenation > So I'm a bit of a lurker here, but I wanted to put in my $.02. > > I'd rather see a dependency on efficiently implemented code in a single place than either replicating the code or using a less efficient algorithm. Replication just means that bugs in the code aren't fixed in all places, adds confusion to users as to which version to leverage, and makes it harder to introduce possible future code improvements. Trading memory for speed can be a meaningless tradeoff in high-volume applications where the number of GCs visibly impacts overall system performance. > > My preference would be for leveraging code that is in a logical place (ala commons-lang) and documenting the dependencies. > > hab > > > -----Original Message----- > From: Martin Cooper [mailto:[EMAIL PROTECTED] > Sent: Sun 2/15/2004 4:21 PM > To: Struts Developers List > Cc: > Subject: RE: string concatenation > > > > > > > -----Original Message----- > > From: David Graham [mailto:[EMAIL PROTECTED] > > Sent: Sunday, February 15, 2004 1:01 PM > > To: Struts Developers List > > Subject: RE: string concatenation > > > > > > Struts has many dependencies already and I'd like to avoid adding one with > > lang. Why not just size a large StringBuffer and trade memory for speed? > > We already have a dependency on Lang, albeit indirectly, so why not take > advantage of it? > > Frankly, I disagree with the push I see from some folks (including Craig on > commons-dev recently) to reduce dependencies between components by > duplicating functionality. The whole point of Commons is to avoid > duplication, so why are people pushing back against using the successful > components that we helped create here in Struts? > > -- > Martin Cooper > > > > > > David > > > > --- Martin Cooper <[EMAIL PROTECTED]> wrote: > > > Rather than add a new string utility class to Struts, which isn't really > > > where it should belong, I think we'd be better off just using this: > > > > > > > > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang > > /StringUti > > > ls.html#join(java.lang.Object[]) > > > > > > Alternatively, you could suggest (on the commons-dev list) adding a > > > variation of your StringHolder class, based on the join() method above, > > > to > > > Commons Lang. > > > > > > -- > > > Martin Cooper > > > > > > > > > > -----Original Message----- > > > > From: nishant kumar [mailto:[EMAIL PROTECTED] > > > > Sent: Saturday, February 14, 2004 5:46 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: string concatenation > > > > > > > > > > > > hi, > > > > I have a performance tuning suggestion which i think will greatly > > > > impact the performance of struts html tags. > > > > String concatenation using StringBuffer is definitely much > > > > better than > > > > using the plus operator but there are scenarios where there are much > > > > better ways than using StringBuffers. Actually struts html tags fall > > > in > > > > those scenarios. > > > > So let me give you an example. this is the code from > > > > renderFormStartElement method of FormTag. > > > > > > > > StringBuffer results = new StringBuffer(); > > > > results.append("<form"); > > > > results.append(" name=\""); > > > > results.append(beanName); > > > > results.append("\""); > > > > results.append(" method=\""); > > > > results.append(method == null ? "post" : method); > > > > results.append("\" action=\""); > > > > .... > > > > str = results.toString(); > > > > > > > > pageContext.getOut().write(str); > > > > > > > > Now lets list the issues with this. > > > > 1. first presizing this buffer is quite difficult (avoided in this > > > > case). here the buffer starts with size 16 and doubles each time the > > > > size is exceeded. This causes unnecessary creation of new char arrays > > > > and redundant copy of data whenever resizing happens. > > > > 2. whenever append is called data is copied from the passed string to > > > > the end of stringbuffer. > > > > 3. finally the whole concatenated data is again copied into another > > > > string. > > > > 4. and then in the end this string is written to a writer, another > > > copy, > > > > which is the only copy required. > > > > > > > > so even if you had presized the stringbuffer correctly, you have > > > copied > > > > the same data thrice instead of just once. And you also create two NOT > > > > needed objects. > > > > > > > > so here is the solution i propose. have a class holding an array of > > > > Strings and keep appending strings to this array and finally print > > > this > > > > array to the writer. something like this. > > > > > > > > private String[] data = new String[256]; > > > > private int size = 0; > > > > > > > > public StringHolder append(String str){ > > > > ensureCapacity(this.size + 1); > > > > this.data[this.size++] = str; > > > > return this; > > > > } > > > > > > > > public void writeTo(Writer out) throws IOException{ > > > > for (int i = 0; i < this.size; i++){ > > > > if (this.data[i] != null){ > > > > out.write(this.data[i]); > > > > } > > > > } > > > > } > > > > > > > > this way only the last copy takes place and you also avoid creating so > > > > much garbage. > > > > > > > > i have attached StringHolder class which does the above task and also > > > > the FormTag after making necessary modification to fit in this class. > > > > >From the code of FormTag you can see that you need to make quite few > > > > changes to get great benefit. > > > > > > > > i have also attached a better implementation of > > > > ResponseUtils.filter(String) method. the logic is on the same lines as > > > > above. > > > > > > > > thanks, > > > > nishant > > > > > > > > -- > > > > nishant kumar <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Finance: Get your refund fast by filing online. > > http://taxes.yahoo.com/filing.html > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]