The company has been moving projects away from ASP .NET to MVC .NET. One of the cited reasons was improved performance. The ASP .NET projects were not the fastest applications available, but were manageable.

The new MVC .NET projects are slower than snails. Every single page element is trying to do an async call to populate metadata elements. There are sometimes 50 or more controls per page due to the industry this software is used in. FML.

Had to time this. The single page with header and footer loads almost instantly. The body, all the dynamic rendering, took over a minute to do so. once rendered, another 30 seconds for the 23 controls to populate data. I'm gonna start looking for a new gig, because once the MVC framework team says they are done, I'm going to be the one fixing this mess.

Sounds like the architecture is s little wrong. Async calls should be non blocking, sounds like they are async but running synchronously. Also sounds like the UI needs addressing, progressive disclosure prioritises the main interface. 50 heavy data load controls being loaded and rendered at the same time just sounds bad to me !

Love my MVC .NET/EF6 projects.

Have you tried using LinqPad to profile individual components for bottle necks?
We found often the problem was a lazy loaded entity, so we just turn lazy loading off completely and demand the developer explicitly includes all foreign keys he will use during page load.

The Stack Overflow MiniProfiler is also a great tool if you can invest a little time implementing it into your existing code.

@Theo20185 are you sure it's the framework?

Because you're speaking of rendering here so unless you use progressive loading I'd say you aren't timing the page load but the rendering.

Like the others, I'm also suspecting this is not an MVC issue. Just like any other framework, you can do it poorly. If this was their first foray into it, it's probably a shit show. Don't worry, most companies have at least one of these projects lingering around.

Also, like @kwilliams mentioned, this could be an EF issue.

@bluescreen, I found out that our framework likes to load up a version, which includes metadata for every screen and every control on those screens. The call stack is doing this once for every control on the screen. That's broken. I showed the profiler to the framework team, and their response was they didn't want to cache it as metadata changes would not be picked up. My response is that seems moronic since the application does not change the metadata, ever, and the cache on th he server is cleared after each release. They say they don't see a performance issue. I'm sending out resumes today :) Good luck to the next developer who gets to maintain this overengineered, overwrapped monstrosity.

@Theo20185 Well that's just a stupid strategy, don't load things you don't need !!!! Good luck looking for a new role, at least you can see the issues with the strategy.