Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: Hnefi on June 03, 2009, 04:30:45 pm

Title: Significant performance bug, with partial solution.
Post by: Hnefi on June 03, 2009, 04:30:45 pm

I've noticed that C::B performance has a few issues on the machine I'm using at work, which is an Intel Core2 6300 running Fedora 10 with 3GB RAM. Not the most powerful box in the world, but it shouldn't be lagging.

One issue I found was that whenever the caret crossed a brace which would then be highlighted, CPU use would climb to 50% (100% on one core) momentarily. After some debugging, I pinpointed the issue to /src/sdk/wxscintilla/src/scintilla/src/Editor.cxx:

Code

void Editor::SetBraceHighlight(Position pos0, Position pos1, int matchStyle) {
	if ((pos0 != braces[0]) || (pos1 != braces[1]) || (matchStyle != bracesMatchStyle)) {
		if ((braces[0] != pos0) || (matchStyle != bracesMatchStyle)) {
			CheckForChangeOutsidePaint(Range(braces[0]));
			CheckForChangeOutsidePaint(Range(pos0));
			braces[0] = pos0;
		}
		if ((braces[1] != pos1) || (matchStyle != bracesMatchStyle)) {
			CheckForChangeOutsidePaint(Range(braces[1]));
			CheckForChangeOutsidePaint(Range(pos1));
			braces[1] = pos1;
		}
		bracesMatchStyle = matchStyle;
		if (paintState == notPainting) {
			Redraw();
		}
	}
}

Removing the range checks removes the issue entirely:

Code

void Editor::SetBraceHighlight(Position pos0, Position pos1, int matchStyle) {
        braces[0] = pos0;
        braces[1] = pos1;
	bracesMatchStyle = matchStyle;
	if (paintState == notPainting) {
		Redraw();
	}
}

However, I'm obviously not sure whether it's actually safe to remove those checks. Could someone offer insight on that point?

If there are no known issues with taking this measure, should I submit this change as a patch as described on the wiki? I only started fiddling with the C::B source today, so I'm not familiar with due process around here.

Title: Re: Significant performance bug, with partial solution.
Post by: JGM on June 07, 2009, 09:54:13 pm

Interesting, that editor performance bug was really popular, nice to see the source of the problem.

Title: Re: Significant performance bug, with partial solution.
Post by: thomas on June 08, 2009, 12:50:24 am

The more important question is... if two if() statements and possibly a call to CheckForChangeOutsidePaint eat 100% CPU on one core, then in the name of all that's holy, how often is SetBraceHighlight called? Even if it was called 100 times per second (which would be about 95 times too often), this shouldn't be a challenge to a 1.8 GHz CPU.

Title: Re: Significant performance bug, with partial solution.
Post by: Jenna on June 08, 2009, 01:05:32 am

I don't have any performance problems due to brace-highlights.
Scrolling through below the bottom or over the top of the screen eats all the power of one of my CPU's. Scrolling through visible text does not matter.
SetBraceHighlight took between 0 and 4 ms (measured with wxStopWatch and including between 1 and 5 calls to C::B's LogManager to show the cumulative results of the single lines in the function). And there was no significant change in CPU usage, expect the one described above.
Also no (visible) changes with or without the range-check.