Owen,
Thanks for your response. In answer to your question, I did what I
thought the documentation said to do in order to scroll the window so
that newly appended text came into view. You are right that I was
creating thousands of marks, something I realize only now. After
playing around with a small benchmark and reading the documentation
more carefully, I realized the mark would move to the end of the
inserted text and did not need to be created each time.
Perhaps the create mark function could be enhanced to detect and reject
(or report) redundant marks? It seems that I had created thousands of
unnamed redundant marks at the end of the text buffer.
thanks and regards,
Mike C.
Owen Taylor wrote:
On Wed, 2006-09-13 at 07:41 -0700, mikecorn wrote:
I had a performance problem and found a work-around.
I think the GTK gurus should know about this.
Scrolling output of text from a text view window got slower and slower as
the
amount of text in the buffer increased.
Here is what I was doing after adding each line of text at the end of the
buffer:
gtk_text_buffer_get_end_iter(textBuff,&iter1);
endMark = gtk_text_buffer_create_mark(textBuff,null,&iter1,0);
gtk_text_view_scroll_to_mark(GTK_TEXT_VIEW(textWin),endMark,0,0,1,1);
After a few thousand lines, the output speed was a tiny fraction of the
initial speed.
I found an easy solution: save the endMark and avoid the call to
gtk_text_buffer_create_mark(...).
Apparently this function is very slow if the text in the buffer is large
(like > 100 KB).
(Is there a good reason for this?).
After this change, the output speed remains very fast (1000s of lines per
second),
even if the buffer has megabytes of text.
My GTK+ version is 2.8.20
The problem isn't, I think, that creating marks is slow for large
buffers, it's that having thousands and thousands of marks for the same
buffer is slow...
Why did you think that your original implementation wasn't a problem?
Sounds like some documentation somewhere needs to be fixed.
Owen
|
