Reading through forums about to to tweak and increase performance, one of the items I found was enabling a swap partition, or file. Maybe an expert can correct me, but I don’t understand how this could possibly help, and probably hurts.
Unix swap, and virtual memory in general, allows physical memory to be extended. A section of the disk is turned into what is essentially very slow memory. When the system starts to run low on memory, the OS moves inactive processes into virtual memory to make space for new or active processes. This works well in general as there are usually a large number of background processes that are idle for long periods of time. If the processes aren’t active, it doesn’t matter if the memory in which they reside is slow.
Android, while a fairly typical (but trim) Linux under the covers, has it’s own mechanism for handling low memory conditions. It terminates the application, but first gives it an opportunity to persist it’s state (via a series of callbacks). For example, a map application might persist a latitude and longitude before it is terminated. When you access the application again, the location is passed back so it appears that the app was running all along. In actuality the app was restarted completely.
Both swap, and Android’s native application swapping mechanism do the same thing, at a high level anyway: they move inactive processes out of physical memory free up space for those that are active. However, which does it more efficiently?
- An Android swap partition must live on your SD card. SD cards are very, very slow memory. They are 100 to 1000x slower than a SIM. They are 10 to 100x slower than a hard drive. They are marginally faster than a network connection. When an application is “swapped out” it is copied into this very slow memory, and copied back to physical memory when it needs to run. On the other hand, when an app needs to be restarted after being terminated by Android, it is loaded not from the SD card but from the device’s (relatively) fast physical memory.
- When an Android app is terminated because of low memory, it decides what information must be persisted to represent it’s state. This can be very, very small. For example, it might be an integer index into a database. When an app is moved into virtual memory, the OS has no idea what’s important. It just moves the application in whole. It can’t be smart about it.
- Having swap actually prevents the native Android memory management scheme from activating. The system sees memory and doesn’t distinguish between physical and virtual. It will therefore prefer swap over the native Android memory management scheme, and won’t activate the native scheme until swap is full.
- Having swap requires some overhead of system resources.
And here’s a few counter arguments that I can imagine,
- The native Android memory management scheme is there for apps, but not for other processes. That is, having swap allows the many processes that run to support the Linux operating system to be moved out of physical memory.
- If you are running AppToSD, point #1 is negated as in that case the apps are being loaded from the SD card not physical memory.