[Motorola Droid 4] Septfox:
Not necessarily.

The problem with it is that yes, in-memory copies should be damn fast, certainly faster than storage; iirc, a benchmark I did a while back was something like 900mb/s (which is actually on the very low end of things for LPDDR2, but I was probably fighting the LMK at the time). But it's not all in-memory work; zram is compressed. It has to be pulled out of RAM, fed through the processor, then stuck back into RAM...all while the OS is trying to allocate both CPU time and memory bandwidth to other things, such as whatever prompted the swapping in the first place.

From a multitasking standpoint, it makes sense to use it. From a performance standpoint...ehh, I would argue that being able to load straight from storage into previously-freed physical RAM would be faster than trying to have our old processor and memory try to juggle things.

That all said, it does have its place in our device, I think. More on that below.

As far as the onboard eMMc goes, benchmarking found it capable of sustained reads of 70-90mb/s, if memory serves. But that particular benchmarking session was a long time ago in SlimKat.

Since we're on the topic of memory, I messed with it quite a bit this afternoon, looking up various things and trying to find places to eke a few more megabytes here and there. Didn't really find anything, it looks like stargo is running us about as lean as he can for official nightlies.

Some of my experimentation involved zram. I found that it can be quite useful for allowing huge apps to run, but only if set to absurd amounts; otherwise the memory manager doesn't seem inclined to use it to any great extent.

Setting it to 800mb/100 swappiness allows Pokemon GO - my new go-to (get it) for stressing the crap out of the LMK - to not only start up, but actually run decently; a feat that was only possible before by toggling the low_ram flag on, and even then it took roundabouts a year to load up and at that point any interruption would bring it to a grinding halt as it tried and failed to multitask.

Following playing the game a few minutes and shutting it down, meminfo reported a whopping 400mb had been swapped to zram. The phone wasn't especially enthusiastic about running for a little while after that, as things swapped back in, but it's recovering.

That in mind, I would think a hybrid approach would work best: moderately aggressive OOM settings (175/165/200 for hidden/provider/empty), a big ol' swap allowance that looks like it should be unreasonable, and high swappiness. In theory, this should try to keep enough memory free to run the phone at its best, but allow a large space to offload otherwise unreclaimable memory pages into in case an elephant decides to sit on your userspace. If better multitasking is desired, lower Hidden_App to discourage the LMK from killing off recently-used, still-active apps and (hopefully) make it lean more towards swapping something out instead.

I wanted to go for stock (60) swappiness, to discourage common use, but in practice that seemed as bad as turning swapping off : \

Also found some specifics on the low_ram flag here, page 23. Seems that setting it:

Disables GPU acceleration (apparently OpenGL is indeed quite memory-heavy, I saw elsewhere it can be upwards of 8mb per instance)

Optimizes allocations in the Dalvik heap (one wonders why this isn't done by default)

Causes the ActivityManager.isLowRamDevice() API to return true

Apparently at the very least some of Google's apps use the API, but the post I read that in is as dated as that PDF, so who knows. The claimed 10%-15% memory savings is in line with what I observed when trying it out, so that's something.

At the end of the day, after all that...don't take my word for it. I'll never claim to be an expert at messing with Android, I'm just trying things and theorycrafting. If you find swapping works better than forcing memory to stay free, by all means, do that. It should definitely be better for multitasking at the least.