You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by bu...@apache.org on 2002/08/15 22:39:36 UTC
DO NOT REPLY [Bug 10282] -
task fails with OutOfMemory errors on big files
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=10282>.
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=10282
<replace> task fails with OutOfMemory errors on big files
sbailliez@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From sbailliez@apache.org 2002-08-15 20:39 -------
IMHO there is not that much to do here. You can sure optimize a little bit,
but due to the undeterministic nature of the GC and the fact that string are
immutable that does not leave much room for improvement without load of codes.
String and StringBuffer are a huge performance burden and the fact that there
is no helper method to work on char array does not help. CharSequence in JDK
1.4 is not even satisfactory at some points.
The only alternative I see is to change everything and manipulate a unique
buffer and manipulate it. That should be non negligible code with a lot of
duplication and endless maintenance burden since this is normally not
particulary enjoyable to work with offsets.
I'm setting this as wontfix since I do not think it is worth the work, but any
submission will be happily considered (assuming also that I do not miss a
simple optimization in this code)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>