Flash Memory, Not Networks, Hamper Smartphones Most 121
Lucas123 writes "New research shows that far more than wireless network or CPUs, the NAND flash memory in cell phones, and in particular smartphones, affects the device's performance when it comes to loading apps, surfing the web and loading and reading documents. In tests with top-selling 16GB smartphones, NAND flash memory slowed mobile app performance from two to three times with one exception, Kingston's embedded memory card; that card slowed app performance 20X. At the bottom of the bottleneck is the fact that while network and CPUs speeds have kept pace with mobile app development, flash throughput hasn't. The researchers from Georgia Tech and NEC Corp. are working on methods to improve flash performance (PDF), including using a PRAM buffer to stage writes or be used as the final location for the SQLite databases."
Re:A truly stupid comparison (Score:4, Informative)
The long term goal would be to minimize the latency and increase the speed of the writes. Doing so lets you return to a low power state as fast as possible, on top of improving performance.
Re:A truly stupid comparison (Score:3, Informative)
Re:Or, you know, maybe (Score:5, Informative)
writing smaller applications? Maybe, you know, stick to one thing and master it instead of spewing forth so many .
An interesting comment, but not the focus of the linked article.
Its not about the size of applications. Large reads into memory of big applications is not the problem, as this happens with sequential reads, which are very fast on the media type they were looking at.
Its the small RANDOM read/write units that cause the problem, the small sqlite database updates to databases stored on the MicroSD card that are the problem.
The recommendations for placing often used sqlite databases in RAMdisk yielded a tremendous performance increase because it eliminates tons of little random read and write operations that tend to be scattered all over the microSD card. This is buried in page 10 of the Actual Research document [usenix.org], but pretty much glossed over in the linked article. This would require a bit of an OS re-engineering, on the part of smartphone OS designers, such as offering APIs to do much of the routine data storage that these apps all end up using. That storage would be in ram, backed up to MicroSD in a more efficient manor.
Programmers tend to heavily use the general-purpose
“all-synchronous” SQLite interface for its ease of use but
end up suffering from performance shortcomings. We
posit that a data-oriented I/O interface would be one that
enables the programmer to specify the I/O requirements
n terms of its reliability, consistency, and the property of
he data, i.e., temporary, permanent, or cache data, with-
out worrying about how its stored underneath.
Yes, ramdisk can go away on a un-planned phone reboot, but if the RAMdisk was used as a cache, and occasionally written to disk performance would be much better, because you find these little sqlite databases used all over Android and IOS.
Re:Could have told you that... (Score:2, Informative)
Your app does not crash because of flash. Your app crashes due to shit coding.
Re:A truly stupid comparison (Score:2, Informative)
They are being compared in this manner because in the US, a network provider made an advert where they "race" two smart phones to prove that their network is faster. That is, they have two phones and click "install" on the market at the same time on both of them, and then we see that one of them installs in 2 seconds flat while the other one takes like 30 seconds to install the the app. The advert is obviously bullshit because even on a wifi connection and broadband, apps never install that fast. This article explains the reason why: the flash memory can't write the data fast enough to keep up with the download speed.
So although users don't have the option to trade one for the other, they do have the option to not be fooled into buying something they don't need and can't use.
Re:Or, you know, maybe (Score:5, Informative)
Its the small RANDOM read/write units that cause the problem, the small sqlite database updates to databases stored on the MicroSD card that are the problem.
The recommendations for placing often used sqlite databases in RAMdisk yielded a tremendous performance increase because it eliminates tons of little random read and write operations that tend to be scattered all over the microSD card.
How about the recommendation to not use sqlite whenever a flat file works better? Do one write instead of database operations which cause multiple blocks to change even if you only change one thing.
And if you have to use SQL for whatever reason, don't use indices unless absolutely necessary. It seldom is, despite what school has taught you. The index has to get updated too, which causes additional non-sequential writes. The minor speed boost you may get from selects are easily eaten up by the major speed bumps you cause on inserts and updates.
An embedded system, which this should be treated as, isn't a miniature version of your desktop computer. And an SD card isn't a miniature version of a hard drive, or even an SDD. You have to think about minimizing writes and especially random writes. Not just minimize the number of high-level-abstracted changes, but actual low-level writes caused by them. Because there isn't a 1:1 correspondence.
Also, memory is at a premium. Dropping pages really hurts speed. Don't rely on garbage collection as a substitute for using less memory or freeing up memory manually.
Don't hang on to resources in case you may need them. Be cooperative, and close the sockets and file handles when you don't use them, because other parts of the system may benefit from that memory. CPU is rarely the issue, so don't worry about CPU outside identified bottlenecks. Worry about being a resource hog, because that causes the entire system to slow down, and drag your app with it.
Re:Or, you know, maybe (Score:4, Informative)
Except that apple are still doing this just fine at 1024x768, and are likely in a few months to be doing it just fine at 2048x1536... The reason the iPhone can do this and android can't is nothing to do with the resolution – it's that iOS has always used the graphics hardware to render the UI.