ABP uses significantly more memory than a regular .NET project

[MJSanfelippo]

Description

Hi, we've been noticing that ABP uses significantly more memory than a brand-new project that doesn't use ABP. This is in apps with basically nothing in them, and that see very little use. This is even more prevalent if using server garbage collection mode (which is default in modern aspnet core). When using server gc, they would balloon up to several gigabytes for basically no reason (no memory leaks in our code, we checked). We switched the first one to workstation gc mode which helped bring the memory down, but it's still way too high for no good reason. For example, here is a project that uses ABP that sees basically no use because it's our dev server:

And here is a project that does not use ABP that sees the same amount of use (that is, basically none, also on our dev server). Also note this is using server gc, not workstation, and it's still using significantly less memory.

As a note, both have auth servers and both have a web api. The startup time of ABP is also much longer than a non-abp project.

[BringerOD]

+1

[jasenf]

Just chiming in here..

what's the expectation?

abp is the exact opposite of a bare bones "regular" .net project. It's a full on framework and packaged application. It has countless internal services along with third party libraries injected to provide hundreds of non-standard out of the box capabilities. Those libraries are naturally going to take up space.

jasen

[MJSanfelippo]

Just chiming in here..

what's the expectation?

abp is the exact opposite of a bare bones "regular" .net project. It's a full on framework and packaged application. It has countless internal services along with third party libraries injected to provide hundreds of non-standard out of the box capabilities. Those libraries are naturally going to take up space.

jasen

The expectation being that it uses much less memory. What could it be doing behind the scenes that's making take up 100s to 1000s of mb more memory, especially when the app is not even being used? I'm using very few of the hundreds of non-standard out of the box capabilities that you're talking about - we really just use the built-in auth server and localization from ABP for 99% of our apps, including the one I posted above.

[jasenf]

Just loading up all the libraries and assemblies getting ready for usage?

I'm sure that could be verified with some simple memory snapshots?

I don't think it really matters if you are "doing anything". The amount of overhead required to orchestrate the large number of libraries loaded up during startup are just going to have a big impact. I could be totally wrong, and happy to have the abp.io team say otherwise, but my assumption is this is just the "cost of doing business" with such a large framework as abp.io.

jasen

[MJSanfelippo]

I'm not specifically talking about startup performance, although that is something I feel could be faster. The point of the issue is about the high memory usage after the app has started up, despite seeing basically no requests.

[jasenf]

I feel ya. I think the two issues are probably related: lots of assemblies to warm up. Nothing related to requests (thankfully, since we don't want all that stuff happening during end user requests).

[MJSanfelippo]

For sure - I recognize I don't have any specifics (I don't really want to be the one to debug what in ABP is eating up all that memory, I don't have the time and I don't feel that it's my job to do it), but figured I'd put it on the ABP team's radar as something to care about.