Re: GTK+ performance problem


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
amount of text in the buffer increased.

Here is what I was doing after adding each line of text at the end of the

      endMark = gtk_text_buffer_create_mark(textBuff,null,&iter1,0);

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
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
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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]