3 ms·

An application that genuinely uses less RAM at any point of its execution, whether that's measured by maximum RSS, average RSS, whatever, is still better. Then

An application that genuinely uses less RAM at any point of its execution, whether that's measured by maximum RSS, average RSS, whatever, is still better. Then you can have more apps running at the same level of swapping. It's true that if you have a lot of free RAM, there's no need to split hairs. But what about when you don't have a lot? I was under the impression that computers should handle a billion Chrome tabs easily. Or like, y'know, workloads that people actually use that aren't always outlandish stress tests.

foldr 2y ago
Sure, the ideal app uses no resources. But it really doesn’t matter how much allocated memory an app retains when in an unused state (if you’re running it on a modern multitasking OS). If there’s any memory pressure then those pages will get swapped out or compressed, and you won’t really notice because you’re not using the app.
- vacuity 2y ago
  It seems like you're saying that if the user acts in certain patterns, the OS will just take care of it. Isn't the point of computers and technology to make it so that users are less restricted and more empowered? If many people do actually notice performance issues particularly around usage of certain apps, then your recommended patterns are too narrow for practicality. You are talking about scenarios where there is no real pressure, the happy path, but that's not realistic.
  - foldr 2y ago
    I’m just saying that it would not make much difference if Electron reduced its idle memory usage. If you use an app infrequently, then it will get paged out and the memory it retains in its idle state will be available for other processes. If you use the app frequently then you care about active memory usage more than idle memory usage. Either way, there is not much to be gained by reducing idle memory usage. Any attempt to reduce it might just increase the wake up time of the app, which might then have to rebuild various data structures that could otherwise have been efficiently compressed or cached to disk by the OS.
    - vacuity 2y ago
      You're still going off of a "happy path" mentality. The user decides when an app should be idle or active, not the OS. The OS therefore pages in and out with no grand scheme and may be out of sync with the user's next action. What of the time taken to page in an idle app's working set? Or, as I addressed from the start, what if the user wants many applications open and there is not much free memory? That means swapping becomes a necessity and not a luxury, performance drops, and user experience declines. I think there is plenty of, perhaps low-hanging is uncharitable, but not unreasonably high fruit to pick so that users can be more comfortable with whatever workload they desire. I don't think we're remotely pushing the limits of the technology here.
      - foldr 2y 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.
        vacuity 2y ago
        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.

foldr 2y ago

Sure, the ideal app uses no resources. But it really doesn’t matter how much allocated memory an app retains when in an unused state (if you’re running it on a modern multitasking OS). If there’s any memory pressure then those pages will get swapped out or compressed, and you won’t really notice because you’re not using the app.

vacuity 2y ago
It seems like you're saying that if the user acts in certain patterns, the OS will just take care of it. Isn't the point of computers and technology to make it so that users are less restricted and more empowered? If many people do actually notice performance issues particularly around usage of certain apps, then your recommended patterns are too narrow for practicality. You are talking about scenarios where there is no real pressure, the happy path, but that's not realistic.
- foldr 2y ago
  I’m just saying that it would not make much difference if Electron reduced its idle memory usage. If you use an app infrequently, then it will get paged out and the memory it retains in its idle state will be available for other processes. If you use the app frequently then you care about active memory usage more than idle memory usage. Either way, there is not much to be gained by reducing idle memory usage. Any attempt to reduce it might just increase the wake up time of the app, which might then have to rebuild various data structures that could otherwise have been efficiently compressed or cached to disk by the OS.
  - vacuity 2y ago
    You're still going off of a "happy path" mentality. The user decides when an app should be idle or active, not the OS. The OS therefore pages in and out with no grand scheme and may be out of sync with the user's next action. What of the time taken to page in an idle app's working set? Or, as I addressed from the start, what if the user wants many applications open and there is not much free memory? That means swapping becomes a necessity and not a luxury, performance drops, and user experience declines. I think there is plenty of, perhaps low-hanging is uncharitable, but not unreasonably high fruit to pick so that users can be more comfortable with whatever workload they desire. I don't think we're remotely pushing the limits of the technology here.
    - foldr 2y 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.
      - vacuity 2y ago
        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.