Comment 3 for bug 871968

I built a version of trunk with -g -pg and managed to get a gmon.out. (Only by running inkscape.exe from within the debugger - the programming tools under mingw are a bit iffy. If run by itself inkscape.exe created a tiny gmon.out file which was almost entirely null bytes) Let the application sit idle for a while, then quit. Did that twice. Results were the same both times.

gprof inkscape.exe gmon.out >killme.txt

Also, while it was running in gdb, sent inkscape an interrupt using debugbreak

  http://www.mingw.org/wiki/Workaround_for_GDB_Ctrl_C_Interrupt

and then ran "bt" on all threads. Did that a few times and the results were similar each time.

Anyway, the bt info and the top of the gprof results are attached. The latter seems to implicate
the handleTimerCB method, which is in swatches.cpp.

Have there been any changes to swatches.cpp in the time frame where the CPU use on Windows increased?

The backtrace on thread 1 always shows it in libglib in g_poll and poll_rest. I kind of doubt that is the issue because if it was every piece of mingw code that used the same polling mechanism would have a similar background CPU level. Unless maybe a timeout value is passed in somewhere as a parameter, and that is now too short, leading to excessive activity during the polling.