Mail Archives: djgpp/1999/06/17/03:20:13
On Wed, 16 Jun 1999, Tom St Denis wrote:
> >Interestingly enough, if I do something else while
> >the compilation runs, like read my mail with Emacs, or type some code
> >into the editor, the compilation time is unchanged. So apparently
> >multi-tasking other virtual machines is NOT what steals the CPU cycles.
>
> Well typing into an editor has high delays which will give time back
> to windows. The 'dos idle interrupt' is used by keyboard handler
> which will give up time while you are typing (remember that the comp
> works at 200 or so MILLION cycles and typing requires so little
> time).
I suppose you never looked at the Emacs sources. If you did, you
would have noticed that for each keystroke Emacs runs gobs of code
which takes a lot of CPU power just to keep up with my typing.
Here's a short sample of the avalanche of activities that take place
when I press a key in Emacs:
- at least two keymaps (one local to the current editing mode,
another global) are looked up for the key, to find which function
this key should invoke;
- for a self-inserting key, like `a', after the character is
inserted into the buffer, several chains of functions that hook
the buffer-change event are run in sequence;
- the editor checks whether I changed the buffer enough for it to be
auto-saved, and if so, invokes the automatic auto-saving;
- if enough memory has been requested since the last garbage
collection, the editor collects garbage, which involves sweeping
the entire space of allocated Lisp objects;
- the redisplay code runs, which involves looking up the character
code in at least two large tables (because I can reprogram every
character to be displayed as another character, or even as some
string), and also the internal multi-byte representation of
non-ASCII characters istranslated to their displayable glyph
(that's how Emacs supports text that mixes non-ASCII characters
from different languages in the same buffer);
- the portion of the buffer that is affected by the insertion is
scanned to change its syntax-sensitive highlighting.
And those are only the immediate things that come to mind, I'm sure
that I left out a lot.
As another data point, consider this: the CPU Usage display jumps to
90% on an otherwise idle machine when I type.
So typing into Emacs is not something I would dismiss when discussing
CPU load.
> If you ran two builds you would notice a huge slow down.
It's not huge, it's almost exactly 50%, since the two virtual
machines simply share the CPU. Which again means that Windows
multitasking between VMs is quite good, at least as far as execution
time is concerned.
> The intitial slow down is from windows which will still swap and give
> time to explorer and the start menu (I think they are seperate
> tasks...).
The WinTop program shows that the Explorer consumes 0% CPU. The only
Windows task that consumes something visible while I type is
SYSDOC32.EXE (whatever that means), and it takes something like 0.5%,
sometimes goes up to 0.84%. Everything else is idling.
> Also disk/io is buffered differntly under windows (VCACHE).
In my experience, the disk caching in Windows is better than on DOS,
because VCACHE has a smarter write-back strategy, and also because
VCACHE is typically larger. For example, I usually see VCACHE using
between 17 and 20 Megabytes of memory on a 64MB machine, but in the
DOS configuration, I don't define such a large cache, because the
allocation cannot be changed on DOS without rebooting, and I sometimes
need to run programs that are _real_ memory hogs.
> btw, what is this thread (in the subject) actualy about? testing
> compilers or windows?
The former. Given my strange experience with comparing the same
programs run on Windows and on DOS, I was worried that some of the
results presented by Salvadore might be skewed by these factors, since
they all were performed on Windows.
- Raw text -