The Android Lag Fix That Really Wasn't

jfruh writes "When Android was first introduced, it got much of its buzz in the open source community, and despite it being a mobile juggernaut backed by huge companies, it remains an open source project that anyone can submit code to. Thus, when a community patch that claimed to reduce the lag that still plagues the platform was created, it rocketed around various community code sites and was widely praised. The only problem: it didn't actually speed Android up."

Comments

How important is "true" randomness, anyway?

[14erCleaner]

If the problem is that they can't generate "random" number fast enough, maybe they could just return 42 when the entropy pool is empty.

You mean that the placebo effect still works?

[toygeek]

This is why "vortex" generators for carburetors are still sold http://www.vorteccyclone.com/ , Magnets for your fuel lines to "align the molecules" http://en.wikipedia.org/wiki/Fuel_saving_device are still sold, and oddly shaped bicycle cranks http://z-torque.com/ are still sold. Its really no surprise that it happens in the software world too. Really, its been happening for a long time. Regcure, anyone?

Re:You mean that the placebo effect still works?

[fuzzyfuzzyfungus]

The surprising thing, in both this Android case and the assorted car-widgets, is not that the placebo effect works; but that the "If it was that easy, why didn't it come from the factory that way" argument hasn't held more sway.

In the case of the 'vortex' device you link to, the argument is essentially that ~$1 worth of stamped metal could markedly improve the performance and fuel economy of most vehicles without other notable modifications. Short of a full-scale Petroleum-industrial-complex coverup, why aren't these things being bolted on at the factory?

In the Android case, it's not like entropy related issues are news to linux users or hardware makers. Devices that do lots of crypto(ie. network gear designed to support a lot of VPN users, http load balancers designed to serve a lot of SSL sessions, etc.) are frequently provided with dedicated hardware RNGs precisely to prevent performance issues on entropy depletion. VIA's more recent CPUs come with an on-die hardware RNG, and you can buy assorted RNGs for various expansion busses if your applications require it.

The issue isn't so much that you can entropy-starve a system and cause it to respond badly; but that(against a background of people already knowing that) Google went and released an OS that is somehow radically more demanding on /dev/random than most linux variants and didn't even notice? That would be a bit of a surprise.

First Post

[Anonymous Coward]

but sent using Android, so...

article doesn't make sense.

[darkHanzz]

The butter project was about latency with user interaction. The issues talks about /dev/random, which is totally unrelated.

Did you even read the thread you linked to?

[buser]

Apparently the OP didn't read the thread he alleges disproves the performance increase. There is actually a very lively discussion going on about it, and while there's a general agreement that it's not as simple as the /dev/random pool getting depleted, there is some evidence that it is related to locking in the UI (see comment 162).

There are four things that make Android laggy

[Miamicanes]

There are basically four things that make Android laggy. The good news is that most of them can be overcome by user-modified firmware. The bad news is that manufacturers and Google are unlikely to ever fix them directly, because it would increase the manufacturing cost of phones by a few cents.

ONE: KILL-VS-SWAP

Android's normal behaviour is to aggressively kill activities and suspended background tasks, then respawn them from scratch when brought back into the foreground or reactivated. The LINUX (and Windows) norm is to simply quit giving them CPU cycles, stash their state into swap space on the hard drive, and resurrect them later.

One reason why this is done is because Android devices, while not necessarily STARVING for flash, don't have it in quite the abundance that a normal computer has hard drive space. There are also concerns about prematurely wearing out flash. The problem is that flash rewrite life estimates are based upon general use of the entire block of memory... but a swap partition gets created in a specific chunk of flash, and that one tiny chunk gets relentlessly hammered. If your erase-rewrite activity gets spread across the whole flash, it would usually take months of active efforts to be destructive before you really caused damage. However, if you create a 256mb swap partition and hammer it relentlessly, you can permanently damage it in a weekend. For this reason, few at XDA will advocate ever using internal flash for swap.

That brings up catch #2... if you swap to microSD (because it's cheaply replaceable should you end up damaging it), you really need class 6 or better. Swapping to class 2 flash will leave you running more slowly than if you left Android to its default behavior. Guess what class of flash invariably comes with the free microSD card shipped with the phone? Class 2.

Making matters worse, the users in the best position to experiment with swap enhancements are Nexus owners. Unfortunately, Google has this near-religious aversion to microSD, and I don't think any Nexus device since the original Nexus One has shipped with a microSD slot. All that said, if you have a rooted and reflashed Android phone with class 6-10 microSD that has a swap partition and a custom ROM that uses it, you MIGHT see a big reduction in lag if you frequently run apps that have "expensive" startup costs (ie, apps that always begin by trying to make a http request to somewhere, or generate cryptographically-secure random numbers, etc).

TWO: DISDAIN FOR 2D GPU ACCELERATION

Historically, Android hasn't done a good job of putting 2D acceleration to good use ICS was a step forward, but you can't help but feel like the GPU support is more symbolic, half-assed, and buried under 400 abstraction layers that fritter away most of its potential. At least, for simple and straightforward "scroll and/or pan the viewport across a large virtual bitmap" type operations.

Compounding the problem is Android's architectural bias towards generating content on the fly, instead of generating humongous virtual bitmaps and keeping them available for instant viewport rendering.

THREE: ANDROID'S MEMORY-MANAGEMENT SUCKS

Building upon 2, and being completely blunt... Dalvik's memory-management totally fucking sucks compared to Java's. ESPECIALLY the way it handles short-lived objects that get repeatedly created in large numbers, and discarded almost immediately.

I dare anyone to disagree. Half the Android API bends over backwards to tiptoe around Android's shitty heap-management by trying to avoid creating and discarding objects for use as short-lived containers.

No, don't give me crap about mobile devices having limited resources compared to desktop computers. That's bullshit, and everyone knows it. Java mostly solved the worst of its memory-management problems around 1.5. Compare the specs of a high-end laptop circa ~2002 with the specs of a Galaxy S3, and arguments about Android devices being "severely resource limited" just kind of fall on the ground and thrash aroun

Re:There are four things that make Android laggy

[Solandri]

That brings up catch #2... if you swap to microSD (because it's cheaply replaceable should you end up damaging it), you really need class 6 or better. Swapping to class 2 flash will leave you running more slowly than if you left Android to its default behavior. Guess what class of flash invariably comes with the free microSD card shipped with the phone? Class 2.

This is a common misconception. The class of the SD card is a rating for sequential write speed, nothing more. It's important for cameras and camcorders - in fact it was developed for camcorders because some memory cards simply couldn't write the video data as quickly as the device was sending it to the card.

For an Android device you're more interested in its 4k random read/write performance. It's basically a computer reading/writing lots of small files, so it'll be most impacted by 4k read/write speeds.

As it turns out, manufacturers can tune a flash card for a certain type of performance. If you tune it for faster sequential speeds, random speeds suffer. Likewise if you tune it for random speed, sequential speeds suffer. The class 10 cards I've benchmarked typically hit 10-20 MB/s on sequential writes, but will bog down to as slow as 0.004 MB/s on random writes (yes, 4 kB/s - it was the card I bought before I learned all this. It took 4 hours to copy 4 GB of sheet music and MP3s to that class 10 card - a blissful 0.28 MB/s). Here are the CrystalDiskMark scores I got for a 32 GB class 4 card I have:

seq: 22.9 MB/s read, 4.3 MB/s write
512k: 22.0 MB/s read, 1.3 MB/s write
4k: 3.3 MB/s read, 1.3 MB/s write

Yikes! Only 4.3 MB/s write speed. Who would ever want that? Well look at the benchmarks for a 16 GB class 10 card I have:

seq: 21.8 MB/s read, 12.0 MB/s write
512k: 21.5 MB/s read, 0.9 MB/s write
4k: 5.7 MB/s read, 0.008 MB/s write (not a typo)

So yeah it's 3x faster at sequential writes. But it's slower at 512k writes, and more than 160x slower at 4k writes. It's definitely a very bad choice for an Android device despite being class 10.

The sweet spot for Android is around class 4 or 6. That gets you good 4k write speeds without punishingly poor sequential write speeds (which are important if you're doing something like copying a movie to the card). That said, not all cards are created equal. The "class 2" Samsung card which came with my phone is hands down the best card I've tested overall. It peaked at 11 MB/s sequential writes (meaning it could've been rated class 10), while 4k random writes were still above 1 MB/s. Sandisk is another company which seems to underrate their cards (and their class 10 cards have better if not stellar 4k random write speeds), which is why they're usually highly recommended for Android devices.

tl;dr - You want a class 4 or 6 card, or a good class 2 card for your Android device. Not a class 10 card.

Re:Does it matter?

[CurunirAran]

Having spent significant time with iOS devices, I can safely say that the notion that they do not lag is FALSE. Having just installed iOS 6 on an iPhone 4, the lag between just opening and closing basic applications is definitely noticeable. Hell, even my father's iPad 2 lags, and it runs on iOS 4!

My S2 Skyrocket, on the other hand, runs Jellybean 4.1.2 just fine, and cases of lag are rare, if any.

The fact is, all devices, get laggy with use, and your bias against Android makes you ignore the lag that the shiny animations of iOS induce.

There is no perfect, lag-free device.