Yes. Since you know what a swap file is consider what it does and how it works, then consider how the swap files on iOS would be different from a "PC".
Since I asked the question I've already considered it to the extent of my knowledge. I'm sure they'd need to be different, but I don't see any insurmountable problems. Anything in particular you think would be a critical blocker to stop Apple implementing swapping between memory and flash?
Since I asked the question I've already considered it to the extent of my knowledge. I'm sure they'd need to be different, but I don't see any insurmountable problems. Anything in particular you think would be a critical blocker to stop Apple implementing swapping between memory and flash?
You don't see any issues with a single on-board NAND chip compared to a HDD or SSD when it comes to read/write performance or lifetime writes?
Here it is right from Apple:
"Disk thrashing can occur when the system spends a disproportionate amount of time handling page faults and reading and writing pages, rather than executing code for a program.
Paging of any kind, and disk thrashing in particular, affects performance negatively because it forces the system to spend a lot of time reading and writing to disk. Reading a page in from the backing store takes a significant amount of time and is much slower than reading directly from RAM. If the system has to write a page to disk before it can read another page from disk, the performance impact is even worse."
I'm just not sure what about the exclusion of the backing store isn't obvious to technical people at this time. There is no conspiracy or anything dubious. Time Cook isn't rubbing his hands and saying "Excellent!" when thinking about this. It's the best way to make iOS efficient, which also includes power management.
Since I asked the question I've already considered it to the extent of my knowledge. I'm sure they'd need to be different, but I don't see any insurmountable problems. Anything in particular you think would be a critical blocker to stop Apple implementing swapping between memory and flash?
I have no idea why akqies went off on a tangent about paging. Memory paging and application swapping are two different things, which from akqies' unhelpful attitude of technical superiority, I would expect him/her to completely understand.
But you asked about swapping, not paging. And I think that your question is a good one. Here's my guess as to the answer why:
iOS can place apps in a state called suspended when they're switched from interacting directly with the user and thus out of foreground state. Suspended means that the app is still in RAM, but is completely dead other than that; it isn't given any CPU time or passed any events (unlike backgrounded apps that can still do some kinds of activities like playing sounds or downloading small amounts of data). A suspended app can be brought back to foreground life very quickly if the user switches to it, but in the mean time it isn't using up any resources beside RAM space.
Apple could easily implement swapping for apps placed in the suspend state. It wouldn't have a huge impact on overall performance, battery conservation, or SSD life if the swapper is configured to be very conservative--to only swap certain apps under very limited conditions. But instead, Apple has explicitly removed swapping from iOS in contrast to OS X (and Android).
Why? I think it is because swapping apps would go against the fundamental design of iOS: The User Comes First. iOS is very explicit and consistent in its emphasis that all apps operate in an unforgiving environment that always puts user interactivity first and foremost. The foreground app always wins over background and suspended apps, because it is the one that is directly interacting with the user. Under iOS, apps have a limited amount of time to go from launch to user-ready, or they are killed. They have a limited amount of time to clean up on exit and get out of the user's way before being killed. They are not allowed to do time-consuming operations on their main threads and thus appear unresponsive, laggy, or jerky to the user. If the foreground app requests more memory and there isn't enough available, backgrounded apps are requested to cede some of their allocated memory (or have it simply taken away), and suspended apps are killed, right then and there, without warning, boom. Not for any of the reasons akqies claimed (though those are nice side benefits). But rather to keep the foreground app running as smoothly and with as much immediacy as possible--to never make the user wait or put up with sluggishness while iOS does some background task, like swapping an app out to disk. Killing a suspended app is virtually instantaneous, and makes the memory from the suspended app immediately available to the foreground app. Killing instead of swapping keeps performance as perceived by the user at its peak.
On a side note, Android, being a Linux variant, can swap apps. It doesn't do so by default, probably for the same reasons that Apple designed swapping out of iOS. But there are Android apps that can turn swapping on. I think it's an interesting example of the contrasting design philosophies between Android and iOS. And if you have access to an Android device, it's fun to play with, and to monkey around with the "swappiness" system parameter. Here's an interesting discussion on swappiness: http://lwn.net/Articles/83588/
Thanks, that's really interesting. If you're right (and I see no reason to think you aren't) then it seems like Apple would rather focus on the here and now of the user experience than the broader experience. i.e. they'll dump your cache of Safari pages on a dime to make your Numbers spreadsheet faster, which you'll appreciate while you're in Numbers, but is hella annoying when you go back to Safari.
Seems to me like there must be somewhere in the middle that meets both needs a bit better, maybe implementing swapping more per-emptively, so app states get swapped into flash when the phone isn't doing anything else and there system identifies (according to some learning rules) that the app is unlikely to be used in the near future. Would be nice.
Or, y'know, put more RAM in the damn devices, even if it requires more power and costs a bit more.
I'm sure Apple are looking at all this, and have reasonable reasons for why they do things. Still annoys me when things aren't perfect though - demand more! :-)
The fact that apps have a "suspended" state on iOS fits nicely with the memory compression technology from OS X, if it were to come over. When the frontmost app needs more memory, background apps could first be compressed, and only if the frontmost app needs still more memory could they be purged.
Sorry guys this is going to sound geeky but did anyone notice the dent on the edge of the previous generation ipad 4. At the risk of sounding like Sheldon cooper, always use a case people.
Comments
Yes. Since you know what a swap file is consider what it does and how it works, then consider how the swap files on iOS would be different from a "PC".
Since I asked the question I've already considered it to the extent of my knowledge. I'm sure they'd need to be different, but I don't see any insurmountable problems. Anything in particular you think would be a critical blocker to stop Apple implementing swapping between memory and flash?
You don't see any issues with a single on-board NAND chip compared to a HDD or SSD when it comes to read/write performance or lifetime writes?
Here it is right from Apple:
Paging of any kind, and disk thrashing in particular, affects performance negatively because it forces the system to spend a lot of time reading and writing to disk. Reading a page in from the backing store takes a significant amount of time and is much slower than reading directly from RAM. If the system has to write a page to disk before it can read another page from disk, the performance impact is even worse."
I'm just not sure what about the exclusion of the backing store isn't obvious to technical people at this time. There is no conspiracy or anything dubious. Time Cook isn't rubbing his hands and saying "Excellent!" when thinking about this. It's the best way to make iOS efficient, which also includes power management.
Received 4 days after launch from on line order.
Amazing, replaced 1st gen, iPad Air's name is true - so lite, screen is sharp.
Camera is waste of space.
Not worried about Safari refresh - this devise is not a work horse like my Mac.
iPad purpose is for notes/books/ magazines/ Pages for dreams & Sketch for visions.
Viewed HOBBIT video on FB - the whole iPad vibrated - case has the less density due to low weight?
No matter - we're buddies!
Received 4 days after launch from on line order.
Amazing, replaced 1st gen, iPad Air's name is true - so lite, screen is sharp.
Camera is waste of space.
Not worried about Safari refresh - this devise is not a work horse like my Mac.
iPad purpose is for notes/books/ magazines/ Pages for dreams & Sketch for visions.
Viewed HOBBIT video on FB - the whole iPad vibrated - case has the less density due to low weight?
No matter - we're buddies!
Replaced my iPad 3 with an Air and, yes, amazing in my hands as well.
Since I asked the question I've already considered it to the extent of my knowledge. I'm sure they'd need to be different, but I don't see any insurmountable problems. Anything in particular you think would be a critical blocker to stop Apple implementing swapping between memory and flash?
I have no idea why akqies went off on a tangent about paging. Memory paging and application swapping are two different things, which from akqies' unhelpful attitude of technical superiority, I would expect him/her to completely understand.
But you asked about swapping, not paging. And I think that your question is a good one. Here's my guess as to the answer why:
iOS can place apps in a state called suspended when they're switched from interacting directly with the user and thus out of foreground state. Suspended means that the app is still in RAM, but is completely dead other than that; it isn't given any CPU time or passed any events (unlike backgrounded apps that can still do some kinds of activities like playing sounds or downloading small amounts of data). A suspended app can be brought back to foreground life very quickly if the user switches to it, but in the mean time it isn't using up any resources beside RAM space.
Apple could easily implement swapping for apps placed in the suspend state. It wouldn't have a huge impact on overall performance, battery conservation, or SSD life if the swapper is configured to be very conservative--to only swap certain apps under very limited conditions. But instead, Apple has explicitly removed swapping from iOS in contrast to OS X (and Android).
Why? I think it is because swapping apps would go against the fundamental design of iOS: The User Comes First. iOS is very explicit and consistent in its emphasis that all apps operate in an unforgiving environment that always puts user interactivity first and foremost. The foreground app always wins over background and suspended apps, because it is the one that is directly interacting with the user. Under iOS, apps have a limited amount of time to go from launch to user-ready, or they are killed. They have a limited amount of time to clean up on exit and get out of the user's way before being killed. They are not allowed to do time-consuming operations on their main threads and thus appear unresponsive, laggy, or jerky to the user. If the foreground app requests more memory and there isn't enough available, backgrounded apps are requested to cede some of their allocated memory (or have it simply taken away), and suspended apps are killed, right then and there, without warning, boom. Not for any of the reasons akqies claimed (though those are nice side benefits). But rather to keep the foreground app running as smoothly and with as much immediacy as possible--to never make the user wait or put up with sluggishness while iOS does some background task, like swapping an app out to disk. Killing a suspended app is virtually instantaneous, and makes the memory from the suspended app immediately available to the foreground app. Killing instead of swapping keeps performance as perceived by the user at its peak.
On a side note, Android, being a Linux variant, can swap apps. It doesn't do so by default, probably for the same reasons that Apple designed swapping out of iOS. But there are Android apps that can turn swapping on. I think it's an interesting example of the contrasting design philosophies between Android and iOS. And if you have access to an Android device, it's fun to play with, and to monkey around with the "swappiness" system parameter. Here's an interesting discussion on swappiness: http://lwn.net/Articles/83588/
Seems to me like there must be somewhere in the middle that meets both needs a bit better, maybe implementing swapping more per-emptively, so app states get swapped into flash when the phone isn't doing anything else and there system identifies (according to some learning rules) that the app is unlikely to be used in the near future. Would be nice.
Or, y'know, put more RAM in the damn devices, even if it requires more power and costs a bit more.
I'm sure Apple are looking at all this, and have reasonable reasons for why they do things. Still annoys me when things aren't perfect though - demand more! :-)
The fact that apps have a "suspended" state on iOS fits nicely with the memory compression technology from OS X, if it were to come over. When the frontmost app needs more memory, background apps could first be compressed, and only if the frontmost app needs still more memory could they be purged.