DO NOT REPLY [Bug 26942] - Parse error using set-property for forward in struts-cfg.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26942. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26942 Parse error using set-property for forward in struts-cfg.xml --- Additional Comments From [EMAIL PROTECTED] 2004-02-15 14:47 --- The simplest thing would then be to restore the functionality to the forward and form-bean type attributes and remove the deprecation. The ActionMapping type feature is not deprecated and still working. We could just follow the same implentation for the other elements. But we do need to fish or cut bait. I would not favor releasing 1.2.0 when we know this functionality is not only deprecated but non-functional :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Struts [2004/02/15]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 866|New|Enh|2001-03-06|Clean Way to Add Parameters to Redirecting Forward| | 3202|Opn|Enh|2001-08-21|OptionsTag.doEndTag - calls method to populate se| | 5395|Opn|Enh|2001-12-12|ActionContext class | | 5566|New|Enh|2001-12-21|html:link bug | | 5739|Opn|Enh|2002-01-08|Struts fails silently in too many places | | 5937|New|Enh|2002-01-21|html:form trims all extensions| | 6686|New|Enh|2002-02-26|make action attribute of html:form tag optional | | 6847|Opn|Enh|2002-03-04|Multiple file upload not possible due to MultiPart| | 7892|Opn|Enh|2002-04-09|Using Multiple Resource Bundles for an Application| | 7902|Opn|Enh|2002-04-10|The exception handling declaration in the DTD does| | 9088|Opn|Enh|2002-05-15|FormTag.getActionMappingURL() assumes 1 servlet ma| | 9616|New|Enh|2002-06-05|Some more Struts docs | | 9748|New|Enh|2002-06-10|attribute labelKeyProperty for Options tag| |10550|New|Enh|2002-07-08|Delegate path-management to ActionForwards| |10551|Opn|Enh|2002-07-08|Allow a struts-config element to extend another | |10552|New|Enh|2002-07-08|create helper objects in struts-config| |10867|Opn|Enh|2002-07-16|Add indexedProperty attribute in html taglibs | |11154|Opn|Enh|2002-07-25|html:link tag extension for multiple parameters | |11733|Opn|Enh|2002-08-15|Make error keys more specific | |12170|Opn|Enh|2002-08-29|Added functionality when extending another definit| |12301|Opn|Enh|2002-09-04|nested:messages Tag does not work as expected | |12313|Opn|Enh|2002-09-04|Chaining of RequestProcessors--contribution | |12342|Ass|Enh|2002-09-05|Add default exception handler attribute to global| |12600|New|Enh|2002-09-12|html:form tag always prepends context path to acti| |13125|Opn|Enh|2002-09-30|Lack of character-set while using html:html ta| |13521|New|Enh|2002-10-11|CombinedDispatchAction| |13544|Opn|Enh|2002-10-11|[exception] support contextRelative paths | |13565|Opn|Enh|2002-10-12|To errors, add prefix, suffix, header, footer at| |13638|Opn|Enh|2002-10-15|add Config Factory| |14068|Opn|Enh|2002-10-29|Why can't I use forwards with exception elements i| |14071|Opn|Enh|2002-10-29|Need clear info on which Struts attributes produce| |14183|New|Enh|2002-11-01|html:img does not support forward attribute | |14471|Opn|Enh|2002-11-12|validator-rules.xml JavaScript fails when field no| |14749|Opn|Enh|2002-11-21|Action input not starting with '/' and not a val| |15023|Opn|Enh|2002-12-03|Use attribute 'id' instead of 'name' in html:form-| |15188|Opn|Enh|2002-12-09|roles attribute of tags and definitions only allow| |15422|Opn|Enh|2002-12-17|Form Tag exportFormName attribute| |15604|Opn|Enh|2002-12-22|Struts framework should use getInstance Method for| |15670|Opn|Enh|2002-12-26|Doc for exception element needs to mention page| |15673|Opn|Enh|2002-12-26|Default Action in ActionMapping | |15805|Opn|Enh|2003-01-05|Enhance ModuleException to allow getting chained E| |15816|Opn|Enh|2003-01-06|html:form focus in pages with several forms | |15849|Opn|Enh|2003-01-07|Incorrect documentation for Developing Your Own M| |15912|Opn|Enh|2003-01-09|Client-side validation fails if not all form-field| |15921|Opn|Enh|2003-01-09|Allow relative actions in struts-config.xml | |15935|Opn|Enh|2003-01-09|WSAD 5.0 Instructions for Struts Example | |15969|Opn|Enh|2003-01-10|Ability to use TilesRequestProcessor even if it no| |16074|New|Enh|2003-01-14|html:form uses 'action' not 'input' to select mapp| |16104|Opn|Enh|2003-01-15|default handler parameter value for LookupDispatch| |16107|Opn|Enh|2003-01-15|Configure if you want to call ActionForm.reset() i| |16207|Opn|Enh|2003-01-17|Add ability to import tile attributes into a java.|
DO NOT REPLY [Bug 14471] - validator-rules.xml JavaScript fails when field not present in jsp
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14471. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14471 validator-rules.xml JavaScript fails when field not present in jsp [EMAIL PROTECTED] changed: What|Removed |Added Component|Validator Framework |Validator Product|Struts |Commons Version|1.1 Beta 2 |unspecified --- Additional Comments From [EMAIL PROTECTED] 2004-02-15 15:34 --- Since all of the javascript has moved to Commons Validator, this is no longer a Struts issue. I know the Javascript has changed a lot, so it may be a complete non-issue, but I'm not qualified to judge. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16634] - reuiredif ignores missing property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16634. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16634 reuiredif ignores missing property --- Additional Comments From [EMAIL PROTECTED] 2004-02-15 15:48 --- Isn't 'requiredif' going to be deprecated in favor of 'validwhen' anyway? Is this still valid? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: string concatenation
hi,
if you look at the source code of the join method then you will find
that it is doing exactly what struts is currently doing, ie using
StringBuffer for concatenation and finally returning a string.
as far as the packaging of the StringHolder class is concerned, it is
not great a concern. only thing i wished to point out was that all the
html tags need a change in this direction. this will make them much
faster and this is really needed as these tags are quite often used.
thanks,
nishant.
On Sun, 2004-02-15 at 07:41, Martin Cooper 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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26486] - enhance required and other validation actions for form reuse
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26486. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26486 enhance required and other validation actions for form reuse --- Additional Comments From [EMAIL PROTECTED] 2004-02-15 19:31 --- Is there any reason why ValidatorActionForm and DynaValidatorActionForm don't serve this purpose? They look up validator forms by the action path, not the form name, allowing you to have different validation rules for the same form bean used in different contexts. http://jakarta.apache.org/struts/api/org/apache/struts/validator/ValidatorActionForm.html http://jakarta.apache.org/struts/api/org/apache/struts/validator/DynaValidatorActionForm.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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?
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]
RE: string concatenation
-Original Message-
From: nishant kumar [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 15, 2004 9:15 AM
To: Struts Developers List
Subject: RE: string concatenation
hi,
if you look at the source code of the join method then you will find
that it is doing exactly what struts is currently doing, ie using
StringBuffer for concatenation and finally returning a string.
Then I suggest you propose a patch to join() on the commons-dev list, along
with tests and preferably benchmarks to demonstrate that your method is
truly faster.
as far as the packaging of the StringHolder class is
concerned, it is
not great a concern. only thing i wished to point out was that all the
html tags need a change in this direction. this will make them much
faster and this is really needed as these tags are quite often used.
Do you have actual benchmarks to show that it would make a significant
difference, or are you going on basis that this is obvious?
--
Martin Cooper
thanks,
nishant.
On Sun, 2004-02-15 at 07:41, Martin Cooper 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]
-
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
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]
RE: string concatenation
--- Martin Cooper [EMAIL PROTECTED] wrote:
-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?
I don't believe that's correct. What component has a dependency on lang
that we use? We need it for testing but it's not included in the Struts
distro.
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?
In the cases I know of the usage of other components is very limited and
not needed. Examples are Digester and BeanUtils using one class from
collections in very few places when we would be better off dropping
collections and using standard Java collections.
David
--
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]
Re: [GUMP@lsd]: jakarta-struts/jakarta-struts failed
Why are we (and others, commons, etc) getting this from lsd.student.utwente.nl? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 15, 2004 5:58 AM Subject: [EMAIL PROTECTED]: jakarta-struts/jakarta-struts failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://jakarta.apache.org/gump/nagged.html and/or contact [EMAIL PROTECTED] Project jakarta-struts has an issue affecting it's community integration. This issue affects 5 projects. The current state is 'Failed', for reason Missing Build Outputs' Full details are available at: http://lsd.student.utwente.nl/gump/jakarta-struts/jakarta-struts.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Sole jar [/data/gump/jakarta-struts/dist/lib/struts.jar] identifier set to project name - Error - Failed with reason missing build outputs - Error - Missing License Output: /data/gump/jakarta-struts/LICENSE - Error - See Directory Listing Work for Missing Outputs - - - - - -- -- G U M P Gump performed this work: Work Name: build_jakarta-struts_jakarta-struts (Type: Build) State: Success Elapsed: 0 hours, 5 minutes, 35 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/data/gump/xml-xalan/java/bu ild/xalan-unbundled.jar:/data/gump/xml-commons/java/external/build/xml-apis. jar:/data/gump/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/data/gump/gump/ work/merge.xml -Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/data/gump/ jakarta-commons/beanutils/dist/commons-beanutils.jar -Djdbc20ext.jar=/data/g ump/opt/jdbc2_0/jdbc2_0-stdext.jar -Dantlr.jar=/data/gump/opt/antlr-2.7.2/an tlr.jar -Dcommons-lang.jar=/data/gump/jakarta-commons/lang/dist/commons-lang -20040215.jar -Djakarta-oro.jar=/data/gump/jakarta-oro/jakarta-oro-20040215. jar -Djdk.version=1.4 -Dcommons-fileupload.jar=/data/gump/jakarta-commons/fi leupload/target/commons-fileupload-20040215.jar -Dcommons-validator.jar=/dat a/gump/jakarta-commons/validator/dist/commons-validator.jar -Dcommons-loggin g.jar=/data/gump/jakarta-commons/logging/dist/commons-logging.jar -Dcommons- digester.jar=/data/gump/jakarta-commons/digester/dist/commons-digester.jar - Dxerces.jar=/data/gump/xml-xerces2/java/build/xercesImpl.jar -Dcommons-colle ctions.jar=/data/gump/jakarta-commons/collections/build/commons-collections- 20040215.jar -Dservlet.jar=/data/gump/jakarta-servletapi-4/lib/servlet.jar dist [Working Directory: /data/gump/jakarta-struts] - struts: [echo] Processing webapp examples static: [echo] Processing webapp examples compile: [echo] Processing webapp examples dist: [echo] Processing webapp examples [jar] Building jar: /data/gump/jakarta-struts/dist/webapps/struts-examples.war init: [echo] Processing webapp tiles-documentation prepare: [echo] Processing webapp tiles-documentation source: [echo] Processing webapp tiles-documentation libs: struts: [echo] Processing webapp tiles-documentation static: [echo] Processing webapp tiles-documentation compile: [echo] Processing webapp tiles-documentation dist: [echo] Processing webapp tiles-documentation [jar] Building jar: /data/gump/jakarta-struts/dist/webapps/tiles-documentation.war dist: dist.source: [copy] Copying 1 file to /data/gump/jakarta-struts/dist [copy] Copying 1 file to /data/gump/jakarta-struts/dist [copy] Copying 1 file to /data/gump/jakarta-struts/dist dist.contrib: dist: BUILD SUCCESSFUL Total time: 5 minutes 30 seconds - Work Name: list_repo_jakarta-struts (Type: Document) State: Success Elapsed: 0 hours, 0 minutes, 7 seconds Command Line: ls -l /data/gump/log/jars/jakarta-struts/jars - total 502 -rw-rw-r--1 ajackgump 510811 Feb 15 05:07 struts.jar - Work Name: list_jakarta-struts_dir1_lib (Type: Document) State: Success Elapsed: 0 hours, 0 minutes, 1 seconds Command Line: ls -l /data/gump/jakarta-struts/dist/lib - total 2201 -rw-rw-r--1 ajackgump 358273 Feb 15 05:03 antlr.jar -rw-rw-r--1 ajackgump 146440 Feb 15 05:03 commons-beanutils.jar -rw-rw-r--1 ajackgump 510516 Feb 15 05:03 commons-collections.jar -rw-rw-r--1 ajackgump 158996 Feb 15 05:03 commons-digester.jar -rw-rw-r--1 ajackgump15454 Feb 15
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
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.
RE: [GUMP@lsd]: jakarta-struts/jakarta-struts failed
-Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Sunday, February 15, 2004 4:03 PM To: Struts Developers List Subject: Re: [EMAIL PROTECTED]: jakarta-struts/jakarta-struts failed Why are we (and others, commons, etc) getting this from lsd.student.utwente.nl? There is no Apache hardware (yet) for Gump runs. The lsd machine is one that Leo Simons has set up to run Gump and send the nag messages. There are plans to dedicate a machine to Gump once we get the hardware in place (which should be fairly soon). -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 15, 2004 5:58 AM Subject: [EMAIL PROTECTED]: jakarta-struts/jakarta-struts failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://jakarta.apache.org/gump/nagged.html and/or contact [EMAIL PROTECTED] Project jakarta-struts has an issue affecting it's community integration. This issue affects 5 projects. The current state is 'Failed', for reason Missing Build Outputs' Full details are available at: http://lsd.student.utwente.nl/gump/jakarta-struts/jakarta-struts.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Sole jar [/data/gump/jakarta-struts/dist/lib/struts.jar] identifier set to project name - Error - Failed with reason missing build outputs - Error - Missing License Output: /data/gump/jakarta-struts/LICENSE - Error - See Directory Listing Work for Missing Outputs - - - - - -- -- G U M P Gump performed this work: Work Name: build_jakarta-struts_jakarta-struts (Type: Build) State: Success Elapsed: 0 hours, 5 minutes, 35 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/data/gump/xml-xalan/java/bu ild/xalan-unbundled.jar:/data/gump/xml-commons/java/external/build /xml-apis. jar:/data/gump/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/data/gump/gump/ work/merge.xml -Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/data/gump/ jakarta-commons/beanutils/dist/commons-beanutils.jar -Djdbc20ext.jar=/data/g ump/opt/jdbc2_0/jdbc2_0-stdext.jar -Dantlr.jar=/data/gump/opt/antlr-2.7.2/an tlr.jar -Dcommons-lang.jar=/data/gump/jakarta-commons/lang/dist/commons-lang -20040215.jar -Djakarta-oro.jar=/data/gump/jakarta-oro/jakarta-oro-20040215. jar -Djdk.version=1.4 -Dcommons-fileupload.jar=/data/gump/jakarta-commons/fi leupload/target/commons-fileupload-20040215.jar -Dcommons-validator.jar=/dat a/gump/jakarta-commons/validator/dist/commons-validator.jar -Dcommons-loggin g.jar=/data/gump/jakarta-commons/logging/dist/commons-logging.jar -Dcommons- digester.jar=/data/gump/jakarta-commons/digester/dist/commons-dige ster.jar - Dxerces.jar=/data/gump/xml-xerces2/java/build/xercesImpl.jar -Dcommons-colle ctions.jar=/data/gump/jakarta-commons/collections/build/commons-co llections- 20040215.jar -Dservlet.jar=/data/gump/jakarta-servletapi-4/lib/servlet.jar dist [Working Directory: /data/gump/jakarta-struts] - struts: [echo] Processing webapp examples static: [echo] Processing webapp examples compile: [echo] Processing webapp examples dist: [echo] Processing webapp examples [jar] Building jar: /data/gump/jakarta-struts/dist/webapps/struts-examples.war init: [echo] Processing webapp tiles-documentation prepare: [echo] Processing webapp tiles-documentation source: [echo] Processing webapp tiles-documentation libs: struts: [echo] Processing webapp tiles-documentation static: [echo] Processing webapp tiles-documentation compile: [echo] Processing webapp tiles-documentation dist: [echo] Processing webapp tiles-documentation [jar] Building jar: /data/gump/jakarta-struts/dist/webapps/tiles-documentation.war dist: dist.source: [copy] Copying 1 file to /data/gump/jakarta-struts/dist [copy] Copying 1 file to /data/gump/jakarta-struts/dist [copy] Copying 1 file to /data/gump/jakarta-struts/dist dist.contrib: dist: BUILD SUCCESSFUL Total time: 5 minutes 30 seconds - Work Name: list_repo_jakarta-struts (Type: Document) State: Success Elapsed: 0 hours, 0 minutes, 7 seconds Command Line: ls -l /data/gump/log/jars/jakarta-struts/jars - total 502 -rw-rw-r--1 ajackgump 510811 Feb 15 05:07 struts.jar
RE: string concatenation
It seems like utter madness to me.
Mad! Mad! I tell you!
Half of commons was split off from struts originally anyhow, and now to go and say we
dont want to depend on it, lets redevelop it yet again internally...
WTF?
Will we then see another cycle where the internally redevloped code is again split off
to form a sort of neo-commons???
shakes head and sighs/
snip
My preference would be for leveraging code that is in a logical place (ala
commons-lang) and documenting the dependencies.
/snip
+1
-Original Message-
From: Hablutzel, Robert [mailto:[EMAIL PROTECTED]
Sent: Monday, 16 February 2004 08:32
To: Struts Developers List; Struts Developers List
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
Develop against released commons versions [WAS: RE: string concatenation]
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
Re: string concatenation
nishant kumar wrote:
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
/*
* $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java,v 1.48
2003/05/17 01:56:51 dgraham Exp $
* $Revision: 1.48 $
* $Date: 2003/05/17 01:56:51 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Struts, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT
RE: string concatenation
Quoting Martin Cooper [EMAIL PROTECTED]: -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? My particular concern on reducing dependencies is with the recent changes in commons-collections -- it's going to lead to disaster. Not for us ... our dependencies are very narrow, and did not get obsoleted ... but for anyone using Tomcat (and that is a *lot* of people) the fact that collections is no longer backwards compatible is a *huge* issue for people who are going to be stuck with needing to put commons-collections.jar into Tomcat's common/lib directory. I've already committed the necessary changes to the CVS tree in commons-digester. When I get back from my trip to Japan next week (speaking at Java Tech Days on the 18th and 19th), I'm going to do the same for the HEAD of commons-beanutils (dependence on collections is mostly about FastHashMap, which we contributed initially; dependence on commons-lang is a really bad idea because we have no need for 99.9% of that stuff). Anyone who depends on commons-collections in a deeper way than we do is totally screwed by the most recent release. That sort of behavior should be condemned, not condoned. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: string concatenation
Quoting Andrew Hill [EMAIL PROTECTED]: It seems like utter madness to me. Mad! Mad! I tell you! Half of commons was split off from struts originally anyhow, and now to go and say we dont want to depend on it, lets redevelop it yet again internally... WTF? Will we then see another cycle where the internally redevloped code is again split off to form a sort of neo-commons??? shakes head and sighs/ snip My preference would be for leveraging code that is in a logical place (ala commons-lang) and documenting the dependencies. /snip +1 -1. The commons-collections folks screwed much of the world (although not us, because we only depend on a couple of classes that weren't moved to new packages without backwards compatible deprecations) with their recent backwards incompatible changes. I'm not interested in supporting that behavior by continuing to depend on them. Put yourself in the position of a sysadmin for a Tomcat 5 installation where some webapps need the old version of commons-collections.jar and some need the new version. What are *you* going to do? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
