21

My coworker posted this question yesterday: 7-second EF startup time even for tiny DbContext.

After taking his code and moving it to a separate solution to isolate it as much as possible, I found that the containing project's platform target had a profound affect on the runtime of the EF startup process.

When targeting x64, I saw that the test took ~7 seconds to spin up the first DbContext and <1 second to spin up the second DbContext (consistent with my coworker's findings who is also targeting x64). However when I switched the platform target to x86, the first DbContext spin up time was reduced by about 4 seconds down to 3.34633 seconds while the second DbContext took the same amount of time as the x64 case.

Given this, it appears the Entity Framework is going through a much different initialization process when targeting a 64-bit system vs 32-bit system. Does anyone have any insight into what is going on under the hood to explain this?

Community
  • 1
  • 1
Sidawy
  • 574
  • 1
  • 3
  • 17
  • Is it maybe assembly probing? You could look at Fusion Log as a quick check on that. – Craig Stuntz Sep 25 '12 at 14:15
  • @CraigStuntz I checked the fusion logs and didn't see anything that came up differently in x86 vs x64. – Sidawy Sep 25 '12 at 15:05
  • 1
    This is interesting. FYI EF does not have any code specific to 32- or 64-bit architecture - it's pure IL. Still the difference is huge. – Pawel Sep 25 '12 at 15:49
  • Your co-worker said that the number of files in the project seemed to affect performance as well. It could be that EF is using reflection to scan through the assemblies, and this is what's taking time. How is the EF context defined? Is it using an .edmx file? Or code first? If code first, are you using the fluent api to map the entities or attributes? This could also be why 32 bit is faster, since 32 bit assemblies are smaller and have less code to scan through. – Erik Funkenbusch Sep 25 '12 at 16:17
  • @MystereMan It is using code first w/fluent api. I have the test running in our main solution and in a solution where it is the only file and the run times are equivalent. So it appears solution/project size has no impact. – Sidawy Sep 25 '12 at 16:38
  • Are you using 4.3 or EF5? Note: If you're using .net 4 then EF5 is really just EF4.4, since you don't get the majority of improvements. – Erik Funkenbusch Sep 25 '12 at 16:40
  • Are you using a unit testing framework to test it? like Ladislav is? Or are you using your regular app? – Erik Funkenbusch Sep 25 '12 at 18:12
  • FWIW we are using TeamCity and VSTest, and spin up databases for our test classes (similar to http://stackoverflow.com/questions/12626331), and we also got a huge speedup by switching to x86, with EF 6.1 – Mark Sowul Nov 22 '16 at 15:17

1 Answers1

11

The issue is fully reproducible. I have just run it and used dotTrace Performance profiler to collect snapshots for both x86 and x64 executions. I got mostly same times as you report. But there is really no obvious difference between x64 and x86 traces - except the x64 takes at least twice the time of x86 everywhere.

But that was tracing of NUnit test run. By running the same test just as console applications I get times like this:

x86: 0,6864012, 0,0468001
x64: 1,0608019, 0,0468001

That looks much better, doesn't it? There is still difference between x86 and x64 but the x64 code can be slower in general for some operations.

The problem at this point is not about EF but about NUnit and its test runner.

Edit:

I did some more testing. Both NUnit's and Resharper's task runner has this issue but it affects only the very first test. All other tests run quickly. xUnit shows the same behavior.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • 2
    You know what they say... "double the bits, double the fun!" Oh wait. That's not right. – BoltClock Sep 25 '12 at 18:00
  • 1
    Very interesting. I ran the same set of traces and saw the same behavior. It begs the question why the interaction between the Nunit runner and EF is resulting in increased runtime in x64. – Sidawy Sep 25 '12 at 18:15