Why the same code in WPF is slower than in Windows Forms?

Question

I made bunch of benchmarks of the framework 4.0 and older and I can't understand why the same code is slower when using WPF compared to Windows Forms:

This is the code, it has nothing to do with the UI elements:

        Random rnd = new Random(845038);
        Int64 number = 0;
        for (int i = 0; i < 500000000; i++)
        {
            number += rnd.Next();
        }

The code takes 5968ms - 6024ms to execute in Windows Forms and 6953ms in WPF.

Here is the post with the downloadable solution: http://blog.bettiolo.it/2010/04/benchmark-of-net-framework-40.html

Answer 1

A lot can happen in six seconds on a Windows machine. I would imagine that the background processing that takes place in WPF is a little different (and carries a little more overhead) than that which occurs in Winforms.

Answer 2

Do you have a form of some kind showing on the screen? I would think the overhead difference for the form may be what you're seeing.

Answer 3

The first loop runs at the same speed for me.

Are you measuring without the debugger attached?

HTH,
Kent

Answer 4

First off, to rule out any environmental factors you would have to run this test for each solution over a period of 24 to 48 hours. Second the actual logic of it being slower is flawed. If you detach any gui gode from this application you will see they both target the same framework ergo they should not be any different.

If you are testing which GUI framework is faster then your test is invalid as it does not play to either ones strength or weaknesses. To test WPF against Winforms in this manner is to miss the fundamental differences between both frameworks.

There is not biased way of testing each framework since both co exist. To say that WPF is faster in terms of rendering complex primitives or expensive GUI operations is flawed as the test would be biased to WPF.

The fact that the underlying model can be so different means that any testing of this nature would be subjective. I do not trust tests of this nature simply because they are either trying to prove an authors point or disprove someone else's methods.

I would not worry about speed simply because if a customer has the ability to run a WPF application properly then the gains or misses will be so minuscule that they will not matter.

Answer 5

When I downloaded the zip file and looked at your code, the problem became obvious: It is not the same code.

Since the two tests have different code, they are compiled differently by the C# compiler and optimized differently by the JIT compiler. Different registers are assigned to local variables. Different calling techniques are used. Different stack offsets are used.

Here are a few differences I noted between the two benchmark methods:

1. They take different parameter types
2. They contain different numbers (9 vs 7) and types of local variables
3. They make different numbers of method calls
4. They have a different number of loops
5. One calls Application.DoEvents() and the other doesn't

My guess is that in your WinForms version of the code, the JIT compiler placed the variable 'i' at a stack offset whereas in the WPF version it placed it in a register, which then needed to be saved on each iteration.

In any case, don't blame the difference on WPF vs WinForms: Blame the difference on having two different tests that look superficially similar but got optimized differently.

Break the testing code out into a static method in a separate class. If you use identical code in both benchmarks I can pretty much guarantee you that you will get identical results.