I'm no OS expert but I'm pretty sure that assuming that app isn't doing anything then it's pages will be swapped out to disk (in essence , quitting the application from a memory perspective) if there are more pressing requirements for the memory.
Yes, but let's say you open an email client to receive notifications. Then you perform various tasks that involve opening new applications for a limited period of time, and they keep running after you're done with them. Eventually they'll use all the memory and the email client, since it's been idle for so long, gets paged to swap.
Now you get a new email notification and you click to open it, which forces the system to page something else and "bring back" the email client, which creates a huge delay between the click and the email window showing up.
If the temp applications had been closed as each task was completed, the email client would've never been paged out, so it'd remain fast when it was needed.
This might seem a contrived example, but if you have some applications that you tend to leave open, it can be hell.
I see what you are saying here, although I suppose in this example the email client is probably doing some polling tasks in the background making it less likely to be swapped.
Surely it would not be difficult to have a paging algorithm that says something like "this program has no open windows or background tasks in operation you should prefer to swap this application's memory over others", no idea whether this is how it currently works or not?
I suppose there is the overhead of doing the swap operation which you would not need to do if you'd simply dumped the contents of the applications memory on the floor. I guess the memory management algorithm could just swap stuff related to state to disk but dump library code completely and reload this as needed.
Memory is so cheap now that people will usually have more of it than they are actually using at any one time so it probably makes sense where possible to still hold recently used applications (state + libs etc) in there if there is no contention for the memory.
I think my overarching point is that OS programmers are pretty smart , I would be slow to assume that they screwed something up in such an obvious way.
Yes, but let's say you open an email client to receive notifications. Then you perform various tasks that involve opening new applications for a limited period of time, and they keep running after you're done with them. Eventually they'll use all the memory and the email client, since it's been idle for so long, gets paged to swap.
Now you get a new email notification and you click to open it, which forces the system to page something else and "bring back" the email client, which creates a huge delay between the click and the email window showing up.
If the temp applications had been closed as each task was completed, the email client would've never been paged out, so it'd remain fast when it was needed.
This might seem a contrived example, but if you have some applications that you tend to leave open, it can be hell.