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]
