GNOME Bugzilla – Bug 498718
Big slowdown due to highlighting with many brackets [regression]
Last modified: 2007-11-23 19:16:20 UTC
Please describe the problem: When gedit shows a text with some configurations of many brackets and have syntax highlighting on, CPU usage goes to 99% and every thing slows down. Steps to reproduce: 1. Open gedit 2. Paste the following text: (13, 12), (14, 12), (16, 12), (22, 12), (25, 12), (27, 12), (30, 12), (33, 12), (35, 13), (38, 13), (40, 14), (42, 14), (44, 14), (46, 15), (48, 15), 3. Turn on syntax hightlighting (I tried Python, C and Java ones). You will maybe already notice a small slowdown 4. Now paste again the text, more times. After just 7-8 pastes (7-8 lines!), gedit becomes basically useless. Actual results: Cpu to 99%, gedit freezes. After some time everything comes OK... until you try to edit text again. Expected results: Under gedit 2.18.1 (Gnome 2.18.1), the same thing is indeed not very fluent, but still much faster... in the end, usable. Does this happen every time? Yes, every time. Other information: The test of the bug was done under Ubuntu 7.10, while the test of the (quite) correct behaviour was done under Ubuntu 7.04.
Could you please try the same thing you were doing but without brackets? E.g. very same text except replace brackets with 'a'. I believe it's a bug with long wrapped lines (which partly was fixed recently), not something related to brackets. Is it one long wrapped line?
YES, it is one long wrapped (you mean that it automatically goes to newline?), and if I decompose it in several real lines, the slowdown disappears. NO, it is not just a wrapped line problem, since I can handle without problems lines that occupy the whole page, as long as they contain normal characters.
(In reply to comment #2) > YES, it is one long wrapped (you mean that it automatically goes to newline?), > and if I decompose it in several real lines, the slowdown disappears. Yes, it's what I meant. > NO, it is not just a wrapped line problem, since I can handle without problems > lines that occupy the whole page, as long as they contain normal characters. It is not just a wrapped line problem, true. What's slow is lot of highlighted things in a line, in your case it's numbers. This problem is partly fixed, and you will be able to test it with the next gtk release (and another part of the problem will hopefully be fixed too). Question is whether the brackets are relevant here: so, if you try the same text with brackets replaced with spaces or pluses (so numbers stay highlighted), do you get same problem? Or just enter bunch of numbers separated by commas or spaces or whatever.
(In reply to comment #3) > Or just enter > bunch of numbers separated by commas or spaces or whatever. OK, now I got it. Yes, if I enter a long line with lot of numbers and no brackets I still have the problem. So it seems exactly what you're talking about. Happy to know it is already solved.
Good. A dup then. Please try it with the next gtk release and comment in #484615 if it's still too bad or not. *** This bug has been marked as a duplicate of 484615 ***