The problem, the researchers say, is partly the way that nonvolatile memory used inside phones and memory cards works. Product specifications suggest these chips should be able to read and write data faster than processors or wireless data links can serve it up, but in practice, they can’t. This is because benchmarks used to categorize memory are for reading or writing bits of data on a disk in sequence, but many of the popular apps in reality access bits in a less ordered way. That shortcoming was shown to be magnified by the way that many of the apps studied used data management code that relies heavily on random data access.
“Random write performance is orders of magnitude worse for mobile device storage,” and slower than a typical 3G network, said Agrawal. “Storage performance has clearly not kept pace with the improvements in the network.”
The NEC researchers tested a handful of strategies that could limit the chokehold of data storage on app performance. Facebook became four times faster when they forced it to use a different system of data caching, for example. That shows that design choices that app developers make can mitigate the data storage bottleneck, although removing that bottleneck would require changes to mobile operating systems and hardware.
Agrawal told Technology Review that he didn’t know how Apple’s iPhone might perform in similar tests. Apple devices use only internal storage, and their technology is similar to that used by Android devices. However, Apple’s iOS operating system and apps built for it store data in different ways.
After Agrawal’s presentation, Eno Thereska of Microsoft Research suggested that the results need to be validated with tests involving real users, to see if they notice the performance limits uncovered. He questioned whether these limits really even mattered. “I can only read a webpage so fast,” he said, “and have to admit I’m pretty satisfied with mobile apps. What is users’ perception of these experiences?”
Agrawal says his group has not yet tested whether users notice memory bottlenecks, but notes that most of their tests replicated how people use their apps. For example, for Google Maps, they timed how long it took to get results after “find directions” was tapped. Agrawal says he is confident that people could tell the difference and do find limitations imposed by memory frustrating. “Why would anyone want to see a 20-second wait if they can get away with five seconds?”
Smaller design teams can now prototype and deploy faster.