Windows 7 and CRiSP Performance

Pierre was complaining about an issue with CRiSP on his Windows 7
box. When he maximizes the screen, CRiSP became unusable. I think I have
fixed it.

We exchanged a number of emails to try and focus on where the problem was.
I couldnt reproduce it at first - nothing obvious.

Eventually I maximized my Win7 VM window, ran CRiSP at full screen,
and watched the perfmeter CPU graph. It was interesting, because at
full screen, CRiSP was using around 15% of a CPU. Normally this
would be unnoticeable, but 15% is far too high, especially if you
are not doing anything.

CRiSP was developed originally on a 16MHz 80286 CPU. Over the
years, CPUs have become hundreds of times faster, and although
CRiSP now does more - 15% of an i7 CPU is "strange".

In the end we narrowed it down to the Hex/Ascii "codes" panel on
the status bar. 10 times a second, the macro updates this panel.
If I ramp this up to 50x, then CRiSP would eat 50% of the CPU. Very
strange, but at least I had narrowed it down.

I spent a while putting in probes and trying to figure out where
the performance is - somewhere in the display code. The more times
that macro triggers, the more work CRiSP has to do. Equally, the
larger the rows*cols of the screen, the more work to do. But, the
problem was never in the area I was expecting.

Eventually, I narrowed it down to the "dotted" current line box, drawn
around the current line, to make it stand out. Although it is the same
code on Linux (X11) and Windows, on Windows, the code is slightly
perverse (using an API function called LineDDA). LineDDA is a horrible
function. It calls a callback function for each pixel to be drawn,
which is great if you want fine degree of control, but a performance
hog when dealing with anything more than a trivial number of dots to draw.

I replaced the call (after a quick stackoverflow.com search) with
some different code, and now the performance is compatible with X Windows
and CRiSP no longer shows up as a problem.

Whilst doing all of this, I found something really strange - and its difficult
to know what it is. If you watch the Task Manager/Performance view,
it will show you the CPU time used. If your machine is idle, you
expect it to be a small number. I would build crisp and run it.
CPU will hover around 1-2% and all is good.

Under some circumstances, the system is showing 34% CPU use but nothing
is attributed to actually using the CPU. No process in the task manager
and nothing in the Resource Meter. This can go on for 5-10 mins.
(I have been having internet connection issues today, so it is
possible that some service is blocking on the broken internet, and
keeps the graph abnormally high). Its not just task manager - but
the fan on my laptop is running hot whilst this happens.

Its annoying because it means I cannot take any performance benchmarks
whilst this ghost performance issue is there.

Many times in the performance monitor, I see periods of
idle, followed by nice bell-curves of CPU usage, even
when I am not using the system. I get 3 or more consecutive bell
curves as the CPU use rises, then falls to zero.

Other times, like now, the performance is flat at 33-34%.
I am assuming that kernel time - e.g. buffer caching or internal
kernel page flushing is the root cause here.

Just had a quick play with perfmon - a good tool - lots of detail,
even too much, but nothign obvious strikes there.

This is a single CPU VirtualBox VM, so its possible that something
strange is happening in the guest interaction that isnt
visible on a real Win7 host.

Post created by CRiSP v11.0.19a-b6606