Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Significant performance bug, with partial solution.

(1/1)

Hnefi:
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();
}
}
}

--- End code ---

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();
}
}

--- End code ---

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.

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

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

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

Navigation

[0] Message Index