Mac Forum / Applications / Virtual PC / April 2005

The reason why they say this is because of the stupidly small code cache
I mentioned earlier.  Reducing the scope of your virtual PC's address
space is their answer for accomodating the severely limited size of the
code cache.

I thought I'd elaborate on my response...

I said:

"The reason why they say this is because of the stupidly small code cache
I mentioned earlier.  Reducing the scope of your virtual PC's address
space is their answer for accomodating the severely limited size of the
code cache."

I find that the problem with Virtual PC's performance is not the size of the
virtual PC... it's the size of the resident applications running within the
virtual PC.

If you have lots of small apps running, and you use these apps
one-at-a-time,
then Virtual PC will happily run them at a surprisingly good speed until you
switch apps (that is, a context switch occurs).  However, if you start to
run
applications that require large amounts of memory, then Virtual PC starts to
suffer badly.

These characteristics show that there is a bottleneck in the code execution
engine in Virtual PC... and that bottleneck, I think, is the code cache.

It's the same characteristics as having a Mac run Photoshop CS on Panther,
with very little (256 MB) physical memory.  The Macintosh virtual memory
system starts to kick in, and the dynamics of virtual memory and working
memory contexts start to affect system performance as your Mac ploughs
through running code in whatever little physical memory it has left.

Virtual PC is no different.  It has the same virtualisation constraints...
because
working memory contexts are involved.  Virtual PC ploughs through coverting
x86 code to PowerPC in whatever little code cache it has, and hence, it has
a
large overhead of converting x86 code which it may have thrown away at some
point in the past.

The "solution" proposed by Microsoft engineers is an effort to reduce the
scope
of the amount of code Virtual PC has to convert.  But all in all, Windows XP
is
too great an operating system, where the amount of common code that has to
be
executed is too large than can fit in the code cache, so Virtual PC becomes
wasteful in throwing away compiled code, and falls into the predicament of
re-compiling code that has been compiled in the past!  Virtual PC performs
best when its working memory context becomes less than the maximum size of
the code cache... which is 28 MB.  And in Windows XP, the chances of that
happening are very slim!

The *real* solution, is to do something about the code cache--it has to be
bigger,
and ideally, it has to be dynamically resizable, automatically, and on
demand.  This
virtualisation design has to be revised if Virtual PC is to see any
measurable
performance gain in the future.

For the meantime, we can't do this... so my suggestion is to watch what you
run
in Virtual PC.  Use Task Manager to see how large your resident applications
are,
and try to keep them as small as you can.  Be aware that the larger the
resident
applications are, and the more you switch between applications, the greater
the
demands you will be placing on Virtual PC to spend more time converting code
rather than running your apps.

On the Mac side, in system preferences, set the color depth to millions.
 That really helped mine.