Lazy Loading is… well… lazy
I find it ironic that we allow our tooling to mask the biggest bottleneck in the system: The database. Having worked with the majority of the ORM tools out there, I can tell you the most common contributor to slow system performance is lazy loading for Data Access.
I?ve seen this one all too many times:
Business guy: The order checkout screen is running slow in production
Dev: It shouldn?t be, it runs great on my machine
Business guy: Well, it is. It takes 10-15 seconds to load order 123
Dev: Let me check, ya hmm, it is slow. I?ll look into it
The developer proceeds to crack open the source where he finds some LOD nightmare data binding mess in the view, or the mapping to the presentation model: ?Customer.Order-> LineItem.Product.Catalog.Vendor.Name?
Because someone wanted to display the Vendor name on the line detail, they just hopped over the graph and loaded the catalog, and then vendor. So here comes the entire catalog! (of course its N + 1)
Why did they do that? Because it is EASY! (and because your boss wanted it yesterday)
The team never knows about it until it?s too late. Yep, it runs fast locally, because we developers only have a small catalog on our machine, I mean ?we don?t want all that data on our box?.
Now I know there are many folks out there saying ?Well that?s just stupid, I would never do that?. Maybe you wouldn?t, but that guy sitting next to you, he will. I tell you, we all do it, again and again.
The result over time is an interconnected web of queries that can bring a system to a crawl.
See my follow up post for some tips I use when designing a data access layer with an ORM