0

Latest approach says about injecting DbContext instance right to the MVC\WebAPI controller. It has a number of pros but I have one question which is not answered yet - performance of the DbContext instance creation which will not be used.

According to this question: What happens when i instantiate a class derived from EF DbContext? DbContext creation is not so cheap operation (both memory and CPU). And it's twice bad when:

  1. Your action doesn't need the DbContext at all (so you have a mix actions which use and not use the DB)
  2. Some logic (e.g. conditions) doesn't allow to access the DbContext (e.q. ModelState.IsValid). So action will return result BEFORE access to the DbContext instance.

So in both (an maybe some other cases) DI creates a scoped instance of the DbContext, wastes resources on it and then just collect it at the end of the request.

I didn't make any performance tests, just googled for some articles firsts. I don't say that it will be 100% lack of the performance. I just thought: "hey man, why have you created the instance of the object if I will not use it at all".

SerjG
  • 3,325
  • 3
  • 30
  • 30
  • Which version of EF do you have? EF-core has this new feature context pooling. – Gert Arnold Sep 25 '17 at 18:13
  • @GertArnold it's CORE. I had an issue with the pool registration and migrations combination. Do you mean that dbcontext pool usage gets rid of the DbContext instantiating? I think that resources will still be wasted (but not so often maybe) Also there is more important question is coming - dbcontext lifetime (caching, change tracker, etc) – SerjG Sep 25 '17 at 18:22
  • 1
    In EF6, context creation was explicitly designed to be a light-weight operation. So I don't understand why context pooling was introduced in ef-core. Frankly, it makes me a bit suspicious toward the costs of context creation in ef-core. I just left a question about this below the docs. But anyway, I wouldn't worry about it too much. Design your controllers thus that they don't contain methods both needing and not needing a context. Optimize stuff when there's a tangible reason to do so. – Gert Arnold Sep 25 '17 at 21:15
  • @GertArnold I believe that there is a difference between creating a context and not using it, and creating a context and using it. The latter will involve some setup which can likely be sped up when using pooling. – poke Sep 25 '17 at 22:16
  • 2
    @poke You may have a point here, although the result of the most expensive operation, model creation, is stored in the internal service provider which (usually) is [one per app domain](https://blog.oneunicorn.com/2016/10/27/dependency-injection-in-ef-core-1-1/). – Gert Arnold Sep 26 '17 at 07:52

2 Answers2

2

Why have you created the instance of the object if I will not use it at all.

Mark Seemann said in his book Dependency Injection in .NET, "creating an object instance is something the .Net Framework does extremely fast. any performance bottleneck your application may have will appear in other place, so don't worry about it."

Please note that Dbcontext enables lazy loading by default. Just by instantiating it, it doesn't have much impact on the performance. So, I would not worry about Dbcontext.

However, if you have some custom classes doing heavy lifting inside constructor, then you might want to consider refactoring those.

If you really want to compare the performance, you could wrap those dependencies with Lazy, and see how much performance you gain. Does .net core dependency injection support Lazy.

Win
  • 61,100
  • 13
  • 102
  • 181
  • could you please provide the proof for the statement: "Dbcontext enables lazy loading by default". Or do you mean lazy loading for navigation properties (which I disable as the first step)? Thank you! I'm still thinking that DbContext constructor makes some initialization and maybe even some heavy operations (event for the CodeFirst approach). It can be warming up, change tracker initialization or whatever. Going to review EF sources in order to understand what's going on in the DbContext constructor. If you have some article about it - I will appreciate it – SerjG Sep 26 '17 at 22:22
0

You could register it as Lazy or you could do what I do and just inject IMyDbContextFactory and then you can call Create() that will return the DbContext when you actually need it (with its own pros/cons). If the constructor doesn't do anything, it won't be a huge hit, but keep in mind that the first time it gets newed up, it will hit the static constructor that goes through and does all the model validation. This hit only happens once, but it is a huge hit.

Daniel Lorenz
  • 4,178
  • 1
  • 32
  • 39