Home/ Questions/Q 4321268
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T08:43:30+00:00

I’m trying to figure out why our software runs so much slower when run

  • 0

I’m trying to figure out why our software runs so much slower when run under virtualization. Most of the stats I’ve seen, say it should be only a 10% performance penalty in the worst case, but on a Windows virtual server, the performance penalty can is 100-400%. I’ve been trying to profile the differences, but the profile results don’t make a lot of sense to me. Here’s what I see when I profile on my Vista 32-bit box with no virtualization:
enter image description here

And here’s one run on a Windows 2008 64-bit server with virtualization:enter image description here

The slow one is spending a very large amount of it’s time in RtlInitializeExceptionChain which shows as 0.0s on the fast one. Any idea what that does? Also, when I attach to the process my machine, there is only a single thread, PulseEvent however when I connect on the server, there are two threads, GetDurationFormatEx and RtlInitializeExceptionChain. As far as I know, the code as we’ve written in uses only a single thread. Also, for what it’s worth this is a console only application written in pure C with no UI at all.

Can anybody shed any light on any of this for me? Even just information on what some of these ntdll and kernel32 calls are doing? I’m also unsure how much of the differences are 64/32-bit related and how many are virtual/not-virtual related. Unfortunately, I don’t have easy access to other configurations to determine the difference.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I suppose we could divide reasons for slower performance on a virtual machine into two classes:

    1. Configuration Skew

    This category is for all the things that have nothing to do with virtualization per se but where the configured virtual machine is not as good as the real one. A really easy thing to do is to give the virtual machine just one CPU core and then compare it to an application running on a 2-CPU 8-core 16-hyperthread Intel Core i7 monster. In your case, at a minimum you did not run the same OS. Most likely there is other skew as well.

    2. Bad Virtualization Fit

    Things like databases that do a lot of locking do not virtualize well and so the typical overhead may not apply to the test case. It’s not your exact case, but I’ve been told the penalty is 30-40% for MySQL. I notice an entry point called …semaphore in your list. That’s a sign of something that will virtualize slowly.

    The basic problem is that constructs that can’t be executed natively in user mode will require traps (slow, all by themselves) and then further overhead in hypervisor emulation code.

    • 0