Comment 1 Brian Bauman 2007-10-30 09:43:32 EDT

Which editor did you see this in?

Comment 2 Leopold Welsch 2007-10-30 09:59:18 EDT

I am not sure, if I could answer the question properly. I guess it is set like this:

TextViewer textViewer.getDocument().set(s)

Does this answer the question?

Comment 3 Brian Bauman 2007-10-30 17:51:35 EDT

Which editor were you using: Text Editor, Java Editor, Manifest.MF/plugin.xml editor, Feature Editor, etc.?

Comment 4 Leopold Welsch 2007-11-05 04:48:42 EST

Perhaps the word 'Editor' might be misleading. I have an Editor, with a Text and a Table. The Text is coded with the above mentioned TextViewer. And in this TextViewer the Error occurs.

On the other hand I have tried as well to increase the Heap-Memory as well and this does not seem to have any kind of influence (i.e. neither the ini-File nor the Arguments changed the Heap-Size of 64MB).

Comment 5 Leopold Welsch 2007-11-05 09:25:06 EST

I have managed somehow to increase the Heap. Then I could see the Heap runs at approx. 60 MB before CTRL-C and increase to about 120 MB. Seems like the Copy-function requires a LOTTT of Heap-Memory.

Since the CTRL-A takes about 20 sec to mark the whole text I wonder what is done there? Marking each character, one by one, adding ...  etc. Is this worth to open a new Bug?

Comment 6 Brian Bauman 2007-11-05 12:41:35 EST

It seems that the exception is coming from doing a large copy with StyledText.  Since this does not appear to be a PDE Editor and instead a custom editor, I am reassigning to SWT.  They might be able to help better answer your questions/address your problems.

Comment 7 Steve Northover 2008-01-22 18:54:21 EST

I don't think there is much we can do.  If the JVM runs out of heap space creating a big string, then all you can do is increase the memory.  I think the reason that the string is so big is that we are writing RTF.

Comment 8 Leopold Welsch 2008-01-23 03:08:24 EST

What I am astonished is about the overhead, which is produced there. 5.1 MB text-characters (=length) will require approx. 60 MB of heap to copy it? Which would mean, that the RTF-overhead is about 60/5=12 => 12 times for a single character?

Sorry, I can barely believe that THIS much overhead is really required. I guess more there might be some kind of leak.

Comment 9 Steve Northover 2008-01-23 09:53:43 EST

Felipe will investigate and get to the bottom of it.  I'm just guessing about the RTF.

Comment 10 Felipe Heidrich 2008-01-23 13:39:34 EST

(In reply to comment #8)
> Sorry, I can barely believe that THIS much overhead is really required. I guess
> more there might be some kind of leak.

You can't say 60Mb is all RTF overhead. You said the memory increase is 60Mb. The file is 5Mb.
StyledText has to transfers: text and rtf. Just to store the text buffer it will need 5Mb per transfer. Plus memory to store temporary java objects (i.e. you can have thousand of StyleRanges for a file that big).

I tested a few softwares, here is my findings:
Software        text       rtf char count
MS Word         "Hi"       3725
MS Write        "Hi"       154
StyledText      "Hi"       137
JavaEditor      GC.java (176613 chars)   578114
MS Write        GC.java (176613 chars)   379735
MS Word         GC.java (176613 chars)   3059070 

Comment 11 Steve Northover 2008-01-23 14:59:54 EST

The guy is running out of memory, why?  If it's not the size of the plain text and RTF strings, then what is it?

Comment 12 Leopold Welsch 2008-01-24 03:24:56 EST

Thx for the reply. Let me add 3 things:

1) Looking for an overhead with 2 chars is not really meaningful. I see it more helpful the compare of more chars. E.g. if you have your GC.java in styled text, how much overhead is there?

If I take your compare, then I see the factor of 3,5 as overhead, but NOT 12! MS-Word might be out of the range, therefore I have tested it as well. But a 6,6 MB file will be saved as a 8,2 MB file. So, I do not even get close to the 3,5 and not even to the factor you have mentioned below.

2) If I have a 6 MB text in the clipboard, then why the he** does it take that long to insert the whole stuff? (I know, another issue, but ....) And this requires as well factor 13 times more Java-Heap then it really needs to have.

3) If you look on the stack-trace, then I have my doubts about the RTF-Writer. cause the Stacktrace, says nothing about a RTF-Writer, but of a Text-Writer.

Analyzing little bit the code, I wonder, why there are so many Strings used? Wouldn't it be more efficient to run with a StringBuffer and convert the whole crap at the very End to a String. Frankly said, no wonder, why Java allocates about that much of Heap. Conversion.

So, not a RTF-issue.

Comment 13 Steve Northover 2008-01-24 10:13:23 EST

I'm sorry I said anything about RTF.  Felipe, just get to the bottom of "the whole crap".

Comment 14 Leopold Welsch 2008-01-25 13:22:08 EST

Uhu, know I understanding the meaning of a String-conversion ;) To my understanding the heap is overused my the many Strings which are good for nothing. Perhaps a Profiler gives a proper idea about the Heap.

Sorry, couldn't resist the impulse to add a new comment ;) Out of the ambigiousity ;)