WCF much slower than WebAPI running same code

Question

I currently have 2 exposed endpoints. The first is WebAPI (.NET 4.6). The second is WCF (.NET 3.5). They are both capable of performing the same calculation, however the WCF is on average 10 times slower. The calculation code in question is contained in a dll, lets call it core.dll. This dll also exposes the WCF endpoints and is used by an ASP.NET site. The webapi dll, lets call it api.dll references core.dll and is used by an SPA. The calculation can be triggered by either client. On average, with my test data, the WCF service takes about 4.5 seconds to perform the calculation, where as the WebAPI takes about 450 milliseconds (or about 10 times faster).

I should note that all database calls are done outside of the measured time frame. All data is retrieved before hand and all updates are made after the calculation has completed.

All things being equal is there any reason I could be seeing this big of a difference in pure processing speed?

I am 100% sure that the data is the same for both clients and they both receive the same result.

WEBAPI Controller
    Service
        GRAB DATA
        start timer
        Process(DATA) -- the same code/class as below
        end timer
        UPDATE DATA
    Service return
WEBAPI Controller return

WCF Endpoint
    Service
        GRAB DATA
        start timer
        Process(DATA) -- the same code/class as above
        end timer
        UPDATE DATA
    Service return
WCF Endpoint return

EDIT: added diagram for clarity (hopefully)

EDIT 2: Thanks for the answers/comments. Unfortunately it doesn't look like anything conclusive will come of this question. My colleagues and I ultimately choose to believe that this just a pure difference in the efficiency of the Framework versions. We ended up restructuring the web service so that the calculation only happens in the WebAPI.

Answer 1

Use a profiler.

Get better data, out of process, without all the hastle. Profile both for CPU usage and memory, GC collections, hot path, etc...

That said...

You're comparing two vastly different .NET versions. That makes it impossible to do a fair benchmark.

.NET 4.6 introduced a new JIT for 64-bit that's significantly faster. And that's just one difference. Too many to list.

If you can't change the .NET version you will never get an accurate benchmark, but can look for suspects. I would absolutely use a profiler, but if benchmarking:

Take a look at the generated IL (pre-JIT) and also ensure you benchmark post-JIT (IL -> machine code).

One easy way is to simply run both benchmarks once (not measured) as a "cold start" before you start the actual benchmark.

Another is to use RuntimeHelpers.PrepareMethod prior to the benchmark to JIT methods so you're not measuring JIT time.

Of course, ensure your benchmark is fair.

Plenty of information out there, but ensure you're using high resolution timers, use a large sample size (repeat many times), Do a GC.Collect() before each measurement, use the same hardware (testing on the same box), etc...

Correctly doing benchmarks in-process (as opposed to profiling) is really not as easy as it looks.

Anything else is just speculation on our part. I couldn't really comment unless you posted real code that would reproduce your behavior.

Answer 2

My call is that you see such a difference because from .net 3.5 to .net 4.6 there were big performance boosts. If you do heavy use of framework elements that could be the issue.

Check the links bellow (They contain information about performance boosts):

• What's new in the .NET Framework

• Version Compatibility in the .NET Framework

• Performance Improves in .NET 4.6

• C# Benchmark .NET 3.5, 4.0 and 4.5

• Top 10 New Improvements Found in the .NET Framework Version 4.6.2