You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2006/05/02 02:26:13 UTC

DO NOT REPLY [Bug 39368] - [lang] replace() length calculation improvement

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39368>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39368





------- Additional Comments From sjr@jdns.org  2006-05-02 00:26 -------
I think it's silly to mark this as a WONTFIX, and the attached test case doesn't
address the problem at hand.

The test shows the call to length() being called only once per iteration of the
main loop. If there are many matches, then length() will be called more times,
and will add more overhead to the function. Of course, there's calls to
append(), substring() and indexOf(), which probably dominate the running time of
the function. 

All the same, why repeat a call multiple times when the result is always going
to be the same? It seems the Sun Java compiler won't save you, because I haven't
managed to get it to "optimize out" a repeated call to length() on an immutable
string.

The proposed solution is small and sensible and there's no good reason not to
apply it.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org