Comment by foldr
2 days ago
You seem to be thinking about memory usage in general and not specifically about memory usage in an idle state, which is what I’ve been talking about in this thread.
Otherwise, what exactly is the alternative you have in mind? Should Electron release allocations manually after a certain period of inactivity and then rebuild the relevant data structures when woken up again? For the reasons I gave above, I suspect that the result of that would be a reduction in overall performance, even if notional memory usage were reduced.
If you just say “Electron should use less RAM overall!” then you are not talking about the specific issue of memory usage in an idle state; you are talking about memory usage in general.
I am engaging with the arguments you are making; I don't think you are engaging with mine. Reread my previous comment. Application designers do not get the luxury of somehow having high memory usage in an idle state but being able to cut down memory usage in an active state. Your idea of the idle state seems to be that the entire system is idle. You are not considering what happens where there is load. The app designer does not decide when the application has the leeway to have high idle memory usage ("oh, Electron idle memory usage of 500MB is fine because swap so it's basically free").
> Free RAM is just RAM that’s doing nothing useful. Better to fill it with cached application states until you run out.
So you recognize that you are only cruising when there is plenty of free RAM. You're setting aside this magical scenario of the idle state, but really you are just being optimistic that users won't suddenly act and overload the system. You are excusing significant waste by saying it won't matter most of the time. Perhaps that's true with certain definitions (i.e. many people on most days don't make their computer thrash), but in practice people notice when they have a problem, and I want to minimize such problems. I am not saying we can do any of this perfectly, but I think there is legitimate room for improvement that you are ignoring. I think it's reasonable to say that, with modest engineering effort, we could make every (say) 800MB Electron app into a 600MB Electron app. If you were running three at once before, now you can run four with a comparable level of performance. I think that's a genuine improvement that isn't some gotcha to you or an unrealistic fantasy.
>Application designers do not get the luxury of somehow having high memory usage in an idle state but being able to cut down memory usage in an active state.
That may be so. However, in that case, it does not make sense to complain about an application using x amount of RAM while not in use, which is the complaint that I was responding to ("it should not use 500MB of memory when it's [sitting in my tray] and not doing anything"). It might make sense to complain about Electron's overall RAM usage. As far as I can tell, that's what you're doing. I don't really have an opinion on that as I'm not familiar with Electron's internals. So on that point there's really nothing for us to argue about.
>Your idea of the idle state seems to be that the entire system is idle.
I'm talking about the state where the application is not being used, not where the entire system is idle. In that state it is easy for the OS to reclaim any RAM the app is using for use by other apps.