Just before stopping render and so, I suggest you to call system.gc() to free memory as you'll be sure that the game will stay idle.
Doing this will cause two effects:

1. RAM usage may be lower while game is minimized
2. CPU usage may be lower after the game would be focused again as it won't need to do a GC too soon.

Hm, I'm not sure how I feel about this. On the one hand, I do see your point somewhat, but on the other hand, System.gc() is widely discouraged for various reasons. In more detail:

• The moment the game goes out of focus indeed does present a good opportunity for GC to run, since it's not needed at that time.
• Calling System.gc() will make MC use more CPU for a while until it's done. I can't be sure how bad it is without testing though.
• What if the user accidentally unfocused the game or only tabbed out for a short time? The GC may well not yet be done by the time the user returns.
• Modern GCs generally do a pretty good job of managing the heap anyway, without needing to be told what to do.
• I'm not sure, but I don't think the RAM would be freed up to the system for other processes to use. Java would instead keep it around to use for future stuff.

I suppose it would be easy enough to implement and gate behind a config option (defaulting to off) for people to experiment with. What do you think about all this?

Hm, I'm not sure how I feel about this. On the one hand, I do see your point somewhat, but on the other hand, System.gc() is widely discouraged for various reasons. In more detail:

* The moment the game goes out of focus indeed does present a good opportunity for GC to run, since it's not needed at that time.

* Calling `System.gc()` will make MC use more CPU for a while until it's done. I can't be sure how bad it is without testing though.

* What if the user accidentally unfocused the game or only tabbed out for a short time? The GC may well not yet be done by the time the user returns.

* Modern GCs generally do a pretty good job of managing the heap anyway, without needing to be told what to do.

* I'm not sure, but I don't think the RAM would be freed up to the system for other processes to use. Java would instead keep it around to use for future stuff.

I suppose it would be easy enough to implement and gate behind a config option (defaulting to off) for people to experiment with. What do you think about all this?

On my personal hacked client I implemented .gc command, and game freezes for less than 1 second (But often less than 0.3 seconds) freeing up to 1 gb of RAM (I have set max amount of ram usage in MC to 4gb). So i think that you should really implement this, and if You think it wouldn't be that stable, make it disabled in settings by default.
EDIT: I made a quick screenshot of the RAM usage before and after system.gc(), here it is: https://i.imgur.com/DkyS2bo.png
CPU is a little higher, but it goes stable again in less than 4 seconds.

All right, I've implemented it! I tested a bit and it does reduce the heap space usage shown in the top right corner of MC, but it has zero outside effect for me (on macOS, checking in Activity Monitor). I think it sometimes makes interacting with other apps hitch a bit when you do so right after unfocusing, too, so I'm definitely leaving it off by default.

Give it a try: dynamic-fps-2.0.4.jar.zip

All right, I've implemented it! I tested a bit and it does reduce the heap space usage shown in the top right corner of MC, but it has zero outside effect for me (on macOS, checking in Activity Monitor). I think it sometimes makes interacting with other apps hitch a bit when you do so right after unfocusing, too, so I'm definitely leaving it off by default.

Give it a try: dynamic-fps-2.0.4.jar.zip

Nice! I think the 0 effect depends on the VM you use. It usually has less effect on OpenJ9, especially with low max heap, and if you just started the game (of course). I'm closing the issue.

All right, I'll go ahead and upload the update to CurseForge then :)