Flash Memory, Not Networks, Hamper Smartphones Most

← Back to Stories (view on slashdot.org)

Flash Memory, Not Networks, Hamper Smartphones Most

Posted by Soulskill on Saturday February 18, 2012 @12:45PM from the at-least-flash-doesn't-do-it-intentionally dept.

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."

121 comments

Min score:

Reason:

Sort:

Or, you know, maybe by Anonymous Coward · 2012-02-18 12:50 · Score: 2, Insightful

writing smaller applications? Maybe, you know, stick to one thing and master it instead of spewing forth so many OSes, languages and nonsense that there's no hope of reigning in the software chaos? But don't worry, the hardware folks will pull a rabbit out of their hats (again), so that software geeks never, ever have to learn or change.
1. Re:Or, you know, maybe by arkane1234 · 2012-02-18 13:13 · Score: 1
  
  While I agree, I don't see it happening... It's almost like inventing another layer of abstraction in programming is a marketting ploy now. We had C for the longest time, then Java & .NET came out and since then it seemed like abstraction was just "the" answer. The sad part is that Java is kind of cool with its pure object orientation & cross platform abilities but the idea just blew up into a new paradigm so to speak...
  That being said, I think objective C is kinda neat.
  
  --
  -- This space for lease, low setup fee, inquire within!
2. Re:Or, you know, maybe by mjjochen · 2012-02-18 13:45 · Score: 1
  
  Of course (abstraction being the answer). You recall, that we will all be programming by interpretive dance soon (said only half-way jokingly).
3. Re:Or, you know, maybe by icebike · 2012-02-18 14:00 · 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, 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.
  
  --
  Sig Battery depleted. Reverting to safe mode.
4. Re:Or, you know, maybe by __aaltlg1547 · 2012-02-18 14:01 · Score: 4, Interesting
  
  A couple points:
  1. Smart phone makers have no control of what crap software you're going to stick on their phone -- only the crap software that comes preinstalled.
  2. The former is the point of why consumers buy smart phones in the first place.
  3. The smart phone makers have a big incentive to find a way to make the hardware faster because running your apps faster is a selling point.
5. Re:Or, you know, maybe by arth1 · 2012-02-18 15:37 · Score: 4, 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.
6. Re:Or, you know, maybe by Tablizer · 2012-02-18 17:22 · Score: 2
  
  In the future, the distinction between desktop and portable will likely get blurrier, and development techniques and related economics will become similar.
  
  --
  Table-ized A.I.
7. Re:Or, you know, maybe by Urkki · 2012-02-18 19:17 · Score: 1
  
  writing smaller applications? Maybe, you know, stick to one thing and master it instead of spewing forth so many OSes, languages and nonsense that there's no hope of reigning in the software chaos? But don't worry, the hardware folks will pull a rabbit out of their hats (again), so that software geeks never, ever have to learn or change.
  Or, you know, maybe mobile phone makers should stop making phones with increasing resolutions and CPU power and ability to do multitouch pan&zoom. It was a neat trick from Apple, first make people expect smooth pan&zoom at paltry 320x480 resolution. And then the resolution creeps up to sizes like today's 800x1280 in the latest tablet-phone hybrids, where people expect apps to take advantage of the resolution, but still have equally smooth scrolling. That's like 6x bandwidth increasnig throught the graphics processing pipeline. CPU has kinda kept up (with multicore), but sadly, flash has not.
8. Re:Or, you know, maybe by beelsebob · 2012-02-18 21:18 · Score: 3, 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.
9. Re:Or, you know, maybe by msobkow · 2012-02-18 22:00 · Score: 2
  
  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.
  100% true!
  The issue is so common that a virtual index that is not maintained by the database is often referred to as a "business index". With small datasets, application performance is often increased overall by relying on full-table scans for non-indexed data rather than applying an index.
  Another situation where this often crops up is keys that have a low variance. For example, a hundred thousand record table where one of the index columns only has a dozen values. There are no hard numbers, but as a rule of thumb, if there are 10% the number of keys that there are records for an expected table size, I test a business index approach to see how the performance works out.
  But most programmers aren't professionals who test performance before releasing code. As long as "it works", they ship it. Performance tuning will only get done if enough paying customers are complaining that the revenue stream is threatened.
  
  --
  I do not fail; I succeed at finding out what does not work.
10. Re:Or, you know, maybe by Urkki · 2012-02-18 22:24 · Score: 1
  
  That's not really relevant to flash memory performance, hardware acceleration is just what puts the bottleneck squarely at flash throughput. If you have N x the pixels on screen, you'll need N x throughput for flash memory, or the app will either load slower, or it will not take advantage of the resolution and needs to resort to real time scaling (which is ok, but far cry from proper "photoshop" scaling quality). Another thing is increase in camera megapixels, and also increase in acceptable thumbnail sizes, due to increased screen resolution. Hardware acceleration only starts to help once image data is in RAM.
11. Re:Or, you know, maybe by Anonymous Coward · 2012-02-18 22:55 · Score: 0
  
  > But most programmers aren't professionals who test performance before releasing code. As long as "it works", they ship it. Performance tuning will only get done if enough paying customers are complaining that the revenue stream is threatened.
  Which is how it should be. If we performance-optimised the crap out of every little thing before ever releasing it, where would we be?
  Besides, how optimised does your $1 flashlight, fart app or todo-list manager really have to be? On the other side of the spectrum we are currently experiencing a renaissance in user-interface design. Tons of amazing apps would never have seen the light of day if the bedroom programmer that made it had to spend her life savings on bringing in the Database Experts before submitting it to the app store.
  Remember that these are typically 1 to 5 dollar niche apps we're talking about here. There's a place for squeezing milliseconds out of the time it takes to complete a task, but this typically not the place. Smartphones barely do multi-tasking anyway - if the app you're currently actively using is "slow", then it is unlikely to slow the rest of "the system" down in any meaningful way.
12. Re:Or, you know, maybe by Walter+White · 2012-02-19 02:25 · Score: 1
  
  How about a recommendation to do DB writes in a separate thread? I know I've seen that recommendation but don't recall if it was in the info published by Google or in third party tutorials. It has always been the case that if you are writing interactive programs, you need to think about spinning anything that can block response to the UI into a separate thread.
  I'm sure that you can program something faster than a database access using flat files. That too has always been the case. However you trade off programming complexity and time/cost to market by doing so.
  Indices for tables. Add database normalization to this category. Indices provide a benefit when the typical workload favors reads of large tables vs. frequent updates. They do require extra writes on update but can significantly reduce the read load when present. They do not benefit every case but can provide a benefit when applied for the right reasons. Normalization likewise can increase the writes required while reducing the possibility of inconsistent records.
  There will always be something that constrains application speed be it processor, RAM speed or quantity, network speed or backing store. Frequently it is the backing store as processor, RAM and network have gotten pretty fast. Make the Flash in a [phone fast enough and something else will determine application responsiveness.
13. Re:Or, you know, maybe by TheRaven64 · 2012-02-19 02:40 · Score: 1
  
  You're assuming that the majority of what is on screen is from raster sources and not vectors. Both Android and iOS make heavy use of vectors throughout the UI and, while these do place a heavy load on the CPU and GPU for scaling, they place very little load on the flash. It's also worth noting that the flash write times are the main problem - read is usually fast enough.
  
  --
  I am TheRaven on Soylent News
14. Re:Or, you know, maybe by TheRaven64 · 2012-02-19 02:41 · Score: 1
  
  This is true, however Android doesn't suck noticeably more than any of its competitors, just in different way.
  
  --
  I am TheRaven on Soylent News
15. Re:Or, you know, maybe by 21mhz · 2012-02-19 02:57 · Score: 1
  
  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.
  In many applications reads (SQL SELECT) happen much more often than writes. In this case, indexing still brings an overall benefit. In fact, the hardware architecture of flash memory is tilted to fast reads versus very slow writes, so if you have to do any writes at all, you already pay the price. The non-sequentiality issue is also mooted by controller sicruitry in bulk flash devices like SD cards, which reallocates logical buffers for wear leveling, hiding bad blocks, and write optimization.
  The real issue with SQL in embedded devices is mainstream transactional semantics applied to flash storage. Often the programmers are not even aware that each INSERT not framed in an explicit transaction causes a full flush to the medium, which may be disastrous not only to this application's performance, but other concurrent file I/O.
  
  --
  My exception safety is -fno-exceptions.
16. Re:Or, you know, maybe by arth1 · 2012-02-19 03:27 · Score: 1
  
  The non-sequentiality issue is also mooted by controller sicruitry in bulk flash devices like SD cards, which reallocates logical buffers for wear leveling, hiding bad blocks, and write optimization.
  This is a common myth, and why I wrote that SDs are not like SSDs. For a CF card, it's somewhat true, but an SD card doesn't have more than very rudimentary controller for basic wear levelling and bad block mapping, and no RAM buffers in which to prepare write optimizations, nor multiple channels in which to service other operations while one expensive operation occurs.
  Don't treat the SD card in a smartphone as if it was an SSD. Both are MLC (or in rare cases SLC), but the similarity stops there. An SD card is designed for sequential reads and writes because it lacks the advanced controllers of SSDs.
  A VW beetle and a Porsche 911 both have four wheels and a combustion engine - and they're both based on designs by Ferdinand Porsche too - but if you try to drive the beetle as if it was a performance car, you'll set yourself up for nasty surprises.
  Avoid random writes. Avoid excessive writes. Avoid concurrent operations.
17. Re:Or, you know, maybe by arth1 · 2012-02-19 03:29 · Score: 1
  
  In the future, the distinction between desktop and portable will likely get blurrier, and development techniques and related economics will become similar.
  In the future, we will have flying cars too.
  Don't be a cargo cult follower and believe that everything will be solved by Moore's law, convergence, or whatever silver bullet seems most promising. Program for reality.
18. Re:Or, you know, maybe by arth1 · 2012-02-19 03:33 · Score: 1
  
  How about a recommendation to do DB writes in a separate thread?
  In one word: no.
  The SD card is for practical purposes a single-threaded bottleneck, which doesn't do concurrent writes and reads like your average SSD.
  Multiple threads for the sake of multiple threads is going to hurt performance by the overhead and extra memory usage. Use multiple threads when you need them, but not to camouflage the underlying problem which you just make worse by doing so.
19. Re:Or, you know, maybe by Walter+White · 2012-02-19 03:58 · Score: 1
  
  In one word: no.
  The SD card is for practical purposes a single-threaded bottleneck, which doesn't do concurrent writes and reads like your average SSD.
  In other words, while a DB thread blocks on a write, the UI thread will not service the interface? That's a disappointment. I wonder if the same is true of the built in flash (which is used by default for application databases.)
20. Re:Or, you know, maybe by beelsebob · 2012-02-19 04:35 · Score: 1
  
  The point being that whether the UI stutters or not is nothing to do with flash load times – it's purely and simply to do with whether the UI code is written in a sane way (i.e. with multiple threads for image loading, and with hardware acceleration used to get it onto the screen).
21. Re:Or, you know, maybe by arth1 · 2012-02-19 05:35 · Score: 1
  
  In other words, while a DB thread blocks on a write, the UI thread will not service the interface?
  It may, if there are no reads or writes for the GUI. Not even reads. Else, you'll likely make a bad problem worse. Parallelism is only good as long as you use resources that are available for it, and keep in mind the overhead of setting it up.
  The blocking on the card can be mitigated by having plenty of RAM - in which case OS caching might cause your parallel read to succeed even though the SD card is busy. But you shouldn't count on that.
22. Re:Or, you know, maybe by Urkki · 2012-02-19 06:07 · Score: 1
  
  UI stutter isn't flash problem, but long app start time, or app UI having nothing to display yet because hasn't loaded yet certainly can be a flash issue. Relatively slow flash might actually reduce cases of UI stutter, since CPU isn't so busy processing data... ;)
23. Re:Or, you know, maybe by zippthorne · 2012-02-19 07:53 · Score: 1
  
  Well, you want the "flashlight" app to be pretty optimized, spending most of its time sleeping, I'd assume. Since you're draining the battery for light, you don't want to be wasting cycles draining the battery for useless heat, too.
  
  --
  Can you be Even More Awesome?!
24. Re:Or, you know, maybe by jedidiah · 2012-02-19 08:26 · Score: 1
  
  Better to be a "cargo cult follower" than to ignore the evidence that is already quite obvious if you just bother to pay any attention to the evolution of these devices.
  Given what's already in these devcies, I find the suggestion that you should avoid something like SQLite of all things due to its "high overhead" simply hilarious.
  Trying to pretend you're running an Atari 400 and can code in nothing but assembler has it's own problems.
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
25. Re:Or, you know, maybe by Tablizer · 2012-02-19 21:00 · Score: 1
  
  It might not even be about convergence, but rather portable devices of tomorrow being as powerful as desktops of today. High-level tools like RDBMS become more economical in terms of development versus hardware concerns as power increases.
  It's similar to how C is used instead of assembler for most embedded apps, such as mid-sized toys.
  
  --
  Table-ized A.I.
26. Re:Or, you know, maybe by arth1 · 2012-02-20 02:30 · Score: 1
  
  It might not even be about convergence, but rather portable devices of tomorrow being as powerful as desktops of today.
  Oh, in some if not all respects, they will be. But you shouldn't count on it and disregard today's devices and throw frugal programming aside based on what may be out in the future.
  If you conserve resources so it runs well on current systems, it will run great on future systems, and give you an edge and enough leeway to expand the app without causing problems. It's a win for everyone.
  Disregarding resource use hoping that the future will take care of it isn't a win for anyone.
27. Re:Or, you know, maybe by Anonymous Coward · 2012-02-20 05:40 · Score: 0
  This is pretty much on the mark.
  Flash has several problems that can't really be eliminated:
  Relatively slow write/erase times
  Endurance limits
  Scaling limits being hit
  It's VERY unlikely these can ever be fixed with Flash as these are fundamental limits of the technology at the device level. This is why there have been an number of alternative NVM (nonvolatile memory) technologies being pulling out of the old bag of tricks and retried again. Most of these have origins dating back to the 1960s and 1970s but were largely abandoned because of implementation problems and cost issues. Flash has reached a point where the end is pretty clearly in view for scaling and many of the performance issues like this are also biting at its ankles.
  One trick is to do what @icebike says: use ram disk. The other which is essentially akin to ram disk is to avoid write-erase cycles to memory in the first place. This is basically what SSD memory controllers are all about: they use caching and logic to strenuously avoid Flash write-erase cycle completely but also to avoid write-erase cycles from being clustered to the same memory locations (because of endurance cycle limits).
  BTW I'm trained as an IC designer and I'm daily involved in leading-edge process technology issues like this.
28. Re:Or, you know, maybe by Tablizer · 2012-02-20 14:00 · Score: 1
  
  In my observation, being first to market and low purchase price seems to trump resource conservation as far as actual sales priority. You can call consumers "stupid" all you want, but that won't change their sales choices.
  
  --
  Table-ized A.I.
29. Re:Or, you know, maybe by sco08y · 2012-02-20 15:20 · Score: 1
  
  Yes, ramdisk can go away on a un-planned phone reboot
  So it's a complete no-go. The point of using a DBMS is that you have some kind of guarantees as to your state.
  By all means, you can push intermediate work to a RAM disk or use it as a cache, but any time you're going to tell the user their changes have been committed, there has to be a call to fsync.
A truly stupid comparison by MrEricSir · 2012-02-18 12:51 · Score: 2, Insightful

Users don't have the option of trading network performance for faster local storage. The two are so unrelated it's not clear as to why we're comparing them (I'd use the term "apples and oranges" but I'm sure that would piss off some anti-Apple trolls.)
And sure, SSDs could be faster, believe me nobody would complain if they were. But after using spinning magnetic storage for decades, SSDs seem blisteringly fast to me.

--
There's no -1 for "I don't get it."
1. Re:A truly stupid comparison by Microlith · 2012-02-18 12:58 · Score: 5, Interesting
  
  SSDs and the eMMC NAND storage inside smartphones are wildly different, even if they are fundamentally the same concept.
  SSDs get all of their speed from massive parallelization, writing to and reading from multiple die at once. Often these die tend to consume a bit more power, allowing for faster overall access. In smartphones, you usually have eMMC as the primary NAND device. These are basically high capacity, soldered down SD cards packed with several high density MLC NAND. You have drastically fewer IO channels, no DMA capability (it's all PIO via the CPU,) and slower NAND due to reduced power requirements.
  This is why watching your memory consumption is essential on mobile devices, and why optimization for each device has to be done. The moment the CPU has to access the NAND, you're going to take a performance hit no matter how many cores you have.
2. Re:A truly stupid comparison by Anonymous Coward · 2012-02-18 13:05 · Score: 0
  
  So this is a thinly veiled advert for PRAM, right?
  Let's face it, there's no big surprise that random writes to flash are incredibly slow - it's been like that for the last decade.
  What exactly are you going to be doing with all that IO? Will your battery last long enough to actually read it all?
3. Re:A truly stupid comparison by Microlith · 2012-02-18 13:09 · Score: 3, 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.
4. Re:A truly stupid comparison by Nemyst · 2012-02-18 13:35 · Score: 4, Funny
  
  The good term is "Apples and Androids", obviously.
5. Re:A truly stupid comparison by obarthelemy · 2012-02-18 13:44 · Score: 1
  
  Yep. pointing out where performance issues come from is soooooooooo useless.
  
  --
  The Cloud - because you don't care if your apps and data are up in the air.
6. Re:A truly stupid comparison by dmitrygr · 2012-02-18 13:54 · Score: 3, Informative
  
  Not even close to correct. All current, last generation, and the generation before that SoCs for phones/Tablets/PDAs support DMA to SDMMC module. Tegra 1/2/3? yes Omap 1/2/3/4/5? Yes QC? Yes Marvell 3x, PXA2xx? Yes
  
  --
  -------
  1. Enjoy your job
  2. Make lots of money
  3. Work within the law
  
  Choose any two.
7. Re:A truly stupid comparison by MrEricSir · 2012-02-18 14:03 · Score: 1
  
  Pointing out performance issues is useful. Using them as an excuse to shift blame is not.
  
  --
  There's no -1 for "I don't get it."
8. Re:A truly stupid comparison by mrmeval · 2012-02-18 14:11 · Score: 1
  
  This is self-refreshing DRAM so as long as it has power it's good.
  http://www.cellularram.com/faq/index.html
  It would not be that expensive to have one 128MB one for long term storage. Micron has one that's very low power though there may be others out there.
  I'm not a fan of flash.
  
  --
  I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
9. Re:A truly stupid comparison by Anonymous Coward · 2012-02-18 14:12 · Score: 1
  
  Well, that'll change once the new high definition DRM is entrenched into every single wafer of flash. Only then will it be safe to let citizens have local storage. Maybe.
10. Re:A truly stupid comparison by Anonymous Coward · 2012-02-18 14:41 · 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.
11. Re:A truly stupid comparison by Anonymous Coward · 2012-02-19 07:43 · Score: 1
  
  So what you're saying is that he's correct on all but one point? That sounds pretty "close to correct" to me....
12. Re:A truly stupid comparison by electrosoccertux · 2012-02-19 12:20 · Score: 1
  
  Not even close to correct.
  snarkiness like that makes slashdot a sore to read, and the author probably a sore in real life as well. Can't we all be more polite?
Flash isn't speedy. :( by Anonymous Coward · 2012-02-18 12:51 · Score: 0

Looks like the Flash isn't as speedy as we thought. :/
1. Re:Flash isn't speedy. :( by Anonymous Coward · 2012-02-18 21:46 · Score: 0
  
  flash itself is SLOW but SSD that use 32 channels of flash in RAID0 are very fast indeed, its just that there is no phone on the market today using SSD, all use ordinary slow flash
2. Re:Flash isn't speedy. :( by unixisc · 2012-02-19 00:31 · Score: 1
  
  For starters, let's be specific about what we're discussing here.
  In all cellphones, you have an RF, a baseband and memory. The memory is typically a combination of NOR Flash and RAM, and this combination of Flash and RAM - either SRAM or DRAM - is a cellphone specific memory product called Multi-chip products (MCP). That's the memory typically used for things like the cellphone firmware and the phone's OS, and is typically there on all phones - entry level ones or high end ones. This flash and RAM is typically high performance, where one typically is not dealing w/ slow access times.
  The apps part of the cellphone is what contains all the extra multimedia features that are not necessary for a phone, but the nice to have things - the stuff like a web browser, multimedia player, camcorder, games, java apps, et al. That's the stuff that goes into a cellphone's internal NAND (not the micro-SD card, mind you, which is used for storing the user's external data, such as videos, photos, music, et al.) In this case, the only reason NAND is used is that it's cheaper than NOR, and the MCPs used here is typically NAND plus DRAM, where the NAND data needed is cached by DRAM b4 being accessed by the processor. Such a solution worked cost-wise due to both DRAM and NAND being cheap, and DRAM being adequately fast (but power-draining, hence the new 'mobile DRAM' standards.
  Now, there have been attempts by flash memory companies into coming up w/ high performance flash devices, using various techniques, such as DRAM interfaces on NOR flash, getting NAND cells and giving them NOR interfaces, and so on. That would also obliviate the need to have separate memory for baseband and apps processors. But guess what - none of them would be as cheap as plain ole vanilla NAND is, making them instantly unattractive to cellphone manufacturers, and also, power consumption would be much higher. Sure, one could possibly achieve an optimal point where both power consumption and performance levels are acceptable, but the costs are still not going to be @ either NAND or DRAM levels. Once phonemakers or carriers or users are prepared to pay those prices, one will see the memory bottleneck disappear.
Why not a ramdrive? by Anonymous Coward · 2012-02-18 12:54 · Score: 2

Why not have the phone offload all the info to a ramdrive and occasionally backup the info to the ssd?
Phones could be blisteringly fast if they used ram this way.
1. Re:Why not a ramdrive? by Kenja · 2012-02-18 12:58 · Score: 2
  
  For much the same reason they dont have RAID-0 in the phone. It's too expensive, and its a PHONE!
  
  --
  
  "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
2. Re:Why not a ramdrive? by Microlith · 2012-02-18 13:01 · Score: 4, Insightful
  
  RAM consumes a lot of power, far more than a NAND disk that can be powered down in between accesses.
3. Re:Why not a ramdrive? by hcs_$reboot · 2012-02-18 15:29 · Score: 1
  
  Even during write operations?
  
  --
  Slashdot, fix the reply notifications... You won't get away with it...
4. Re:Why not a ramdrive? by viperidaenz · 2012-02-18 18:11 · Score: 1
  
  DRAM consumes a lot of power. SRAM consumes practically none.
5. Re:Why not a ramdrive? by Anonymous Coward · 2012-02-19 00:41 · Score: 0
  
  Do you have any idea what are you talking about?
6. Re:Why not a ramdrive? by 21mhz · 2012-02-19 03:04 · Score: 1
  
  Do you have any idea what are you talking about?
  The GP probably does, but SRAM is still prohibitively expensive for any practical memory size for a smartphone.
  
  --
  My exception safety is -fno-exceptions.
I would like faster flash memory by CoolVC · 2012-02-18 12:56 · Score: 1

It would be nice if it were faster. I backed up and downloaded the pictures off my iPhone to my computer today. How long did it take? 3 hours.
1. Re:I would like faster flash memory by robogun · 2012-02-18 14:00 · Score: 1
  
  The flash memory isn't what's holding it back. Sounds like whatever software you're using to bridge your locked-down device to the computer is slowing down the process.
  Many devices hook up directly via USB2.0 and/or have removable flash cards which download at 2GB/min, these may save you a lot of time if this is really a problem.
2. Re:I would like faster flash memory by Lumpy · 2012-02-18 15:43 · Score: 1, Troll
  
  That "software bridge" is called the craptastic USB stack that Microsoft uses on windows 7.
  Even if you open the iphone from the file manager and grab them by hand it takes forever. USB2.0 is utter crap for any large amounts of data transfer. Small single files? good, sustained data transfer is garbage. Apple was stupid for removing the Firewire interface from the ipod and iphhone.
  12 gigs of photos over USB 2.0 is slow as hell simply because the USB2.0 speeds are slow as hell.
  
  --
  Do not look at laser with remaining good eye.
3. Re:I would like faster flash memory by arth1 · 2012-02-18 15:59 · Score: 2
  
  Reading 12 gigs of photos over high-speed USB 2.0 isn't that bad when you do it from a reasonably fast card and dedicated card reader. You can typically get 360 Mbps (of the 480 Mbps advertised), which equals 45 MB/s, or about 5 minutes, if your HD can keep up with writing that fast.
  If you use your phone as a card reader, don't expect anywhere near that speed. The phones aren't optimized for that, unlike a card reader.
4. Re:I would like faster flash memory by BitZtream · 2012-02-18 18:12 · Score: 1
  
  I work for a company that sells USB flash memory devices. We've sold some rather high end ones ... I've NEVER seen 45MB/s over USB in my life, I'm fairly certain due to over head in the USB protocol that its technically impossible to do, even if its technically possible, the reality of it is that no actual USB product of any kind does anywhere near the full 480mbs that USB has when you look at the spec sheets.
  My single WD 5400 RPM green laptop drive can write a sustained 80MB/s, not sure where you've found a drive so crappy it can't sustain 45.
  Have you ever actually done any of this stuff you're claiming?
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
5. Re:I would like faster flash memory by viperidaenz · 2012-02-18 18:17 · Score: 1
  
  My 7 year old 2.5" USB hard drive gets sustained 30MB/sec transfer rates over USB2. The hard drive gets similar speed plugged into an IDE bus. That's on Windows 7. 12GB would take 7 minutes. The bottleneck in this picture is the hard drive platter speed and density. Not USB2. Not Windows 7.
6. Re:I would like faster flash memory by drsmithy · 2012-02-18 23:22 · Score: 1
  
  You won't get much more than 35MB/sec out of a USB2 device, no matter what's backing it.
7. Re:I would like faster flash memory by spire3661 · 2012-02-19 07:16 · Score: 1
  
  I cant get more then 30MB/s out of USB 2.0, ever. Hell my NAS over gigabit is faster then USB 2.0
  
  --
  Good-bye
Cut back a little by Waccoon · 2012-02-18 12:57 · Score: 4, Insightful

While I sympathize with developers who have ambitious ideas, the bottom line is that you have to develop within the limitations of the hardware. If your software is too slow or otherwise suffers in performance, then your software is simply too slow.
Cue stories about how RAM chips were too slow to keep up with cutting-edge video controllers in the 90's.
1. Re:Cut back a little by tuxicle · 2012-02-18 13:02 · Score: 2
  
  What about stories of how RAM chips today are too slow to keep up with cutting edge CPUs?
2. Re:Cut back a little by Anonymous Coward · 2012-02-18 13:59 · Score: 0
  
  There aren't any. RAM speed doesn't have much bearing on the speed of modern CPUs. DDR3-1333 is good enough for pretty much everything, and DDR3-1600 is enough for the rest. AMD's APUs can make good use of faster memory (rated up to DDR3-1866, I think), but that's more for the graphics part of the chip - it's well-known that graphics processors are memory bandwidth hogs.
3. Re:Cut back a little by izomiac · 2012-02-18 14:08 · Score: 1
  
  IMHO, it's related to how powerful x86 hardware has become. There's probably a generation of programmers that haven't really grasped the concept of various operations having a cost.
  
  On a desktop you can write back and forth to disk rather quickly, and only power users will notice the delay, so many programs do so annoyingly frequently (e.g. it takes one million writes to boot Windows). Now that mobile devices are gaining popularity, the philosophy of "why optimize, it already runs fast enough on my hardware" is starting to show its weakness.
  
  Of course, that's why I chose to only program as a hobby. I can waste all the time in the world on premature optimization just for the heck of it.
4. Re:Cut back a little by bloodhawk · 2012-02-18 15:19 · Score: 1
  
  RAM speeds have not been a significant issue for some time now. Go and read some of the performance tests done recently on various speed RAM, even jumping from 1333 to something like 2133 DR3 RAM has such an insigificant performance change on the rig that it is clear memory is not the bottleneck nowadays. The Bus, HDD etc are the bottlenecks that hurt more than anything else.
5. Re:Cut back a little by viperidaenz · 2012-02-18 18:21 · Score: 1
  
  DRAM latency hasn't changed much in 10 years. Your 2133 ram will have the same latency has 1066 ram.
  Now think why CPU's with large SRAM caches perform much better than those without. It's not like the extra few MB makes the difference. Its the 1 - 3 cycle latency
6. Re:Cut back a little by tlhIngan · 2012-02-18 18:45 · Score: 5, Interesting
  
  RAM speeds have not been a significant issue for some time now. Go and read some of the performance tests done recently on various speed RAM, even jumping from 1333 to something like 2133 DR3 RAM has such an insigificant performance change on the rig that it is clear memory is not the bottleneck nowadays. The Bus, HDD etc are the bottlenecks that hurt more than anything else.
  False.
  RAM speed does have a significant impact. It's just that cache hides a LOT of the impact. If you ever disable the cache on your CPU, your computer would feel like it was 15 years old - it's that slow.
  Now, one thing about RAM - RAM hasn't actually gotten significantly faster - the clock speeds may have gone up, but the latencies have gone up as well. The faster RAM may have true access times (measured in nanoseconds) close to that of the slower one, especially the cheaper RAM.
  But a modern CPU is very cache dependent. Hell, even the little ARM in your smartphone suffers tremendously when cache is off. (I should know - I've had to do actual timing tests of the ARM caches.).
7. Re:Cut back a little by TheRaven64 · 2012-02-19 02:52 · Score: 1
  
  There's probably a generation of programmers that haven't really grasped the concept of various operations having a cost.
  The problem here is that they are taught high-level languages. In C, it's pretty easy to look at some code and figure out - roughly - how much it will cost. In Java, it's a lot harder. In JavaScript, not only is it even harder, the cost can vary dramatically between implementations. If you know an assembly language or C, then you can easily think 'how is this actually implemented?' when you write something in a high-level language. If you don't, then it's very hard to perform this translation. And guess what has been slowly disappearing from curricula for the last two decades...
  
  --
  I am TheRaven on Soylent News
8. Re:Cut back a little by electrosoccertux · 2012-02-19 12:22 · Score: 1
  
  DDR3-1600 latencies are twice that of DDR2-800 latencies because the clock speed is twice as fast.
so you want a phone to have 4-32GB RAM disk by Joe_Dragon · 2012-02-18 12:59 · Score: 2

so you want a phone to have 4-32GB RAM disk + say 256-512MB + system ram
1. Re:so you want a phone to have 4-32GB RAM disk by Anonymous Coward · 2012-02-18 17:37 · Score: 0
  
  I think the idea is to have the API's allow you to make your data changes in RAM, and have those changes commit to persistant storage later... not to add an additional RAM storage device in the phone.
2. Re:so you want a phone to have 4-32GB RAM disk by TheRaven64 · 2012-02-19 02:46 · Score: 1
  
  No. You want a separate RAM cache, with its own battery, that can persist between crashes and phone power cycling. The idea would be that changes would be stored there and later flushed to the flash if they had not been superseded after a while. You want something that has the same persistence guarantees as a flushed write to flash, but at a lower cost. Having a small amount of RAM (32MB would probably be enough) with a separate - small - battery or capacitor. When the phone loses power, it would write its contents out to the flash. This is not a new idea - server RAID controllers do the same thing.
  
  --
  I am TheRaven on Soylent News
Now this I believe by DigiShaman · 2012-02-18 13:03 · Score: 1

Absolutely. From Droids to Black Berry phones, I've long suspected faulty storage. When a phone become non-reponsive because you received or opened an email or installed a new app, chances are the pending writes are not going through like they should. Same goes for browsing the web. History and cache are constantly being read and written back to the phone. If the problem is with the storage, that too will effect performance and stability with shoddy flash memory.

--
Life is not for the lazy.
1. Re:Now this I believe by TheTurtlesMoves · 2012-02-18 22:12 · Score: 1
  
  My android has no UI lag and is instantly responsive as far as I can tell.
  
  --
  The Grey Goo disaster happened 3 billion years ago. This rock is covered in self replicating machines!
Choose two... by Anonymous Coward · 2012-02-18 13:11 · Score: 4, Insightful

Reliable, fast, energy efficient. Choose two.
1. Re:Choose two... by Nerdfest · 2012-02-18 13:58 · Score: 1
  
  Sometimes we don't even get to be able to choose one. These days, you should also add "open" to the list in the case of computer hardware.
2. Re:Choose two... by BitZtream · 2012-02-18 18:18 · Score: 0
  
  You add open to your list, the rest of us have shit to do rather than play around Stallman's land of politics and agenda viruses.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
3. Re:Choose two... by Anonymous Coward · 2012-02-19 00:59 · Score: 0
  
  If you add open then you just get to choose one more.
4. Re:Choose two... by electrosoccertux · 2012-02-19 12:23 · Score: 1
  
  apple chooses all 3 at the expensive of some other ones you didn't list like "openness" or "freeness" or something
Can't make it slow if you can't get it by Anonymous Coward · 2012-02-18 13:17 · Score: 3, Insightful

Flash memory may be responsible for slowing things down, but you can't slow it down if you don't have it.
I would kill for a happy medium between $35 for unlimited data that barely works (Virgin) and $80 and a first born child for 2gb/month for decent coverage (Verizon, AT&T, T-Mobile...). A little legislation wouldn't be a bad thing, though I understand I might think differently if I had campaign donations to worry about.
1. Re:Can't make it slow if you can't get it by anagama · 2012-02-19 07:17 · Score: 1
  
  Well, T-Mobile's most expensive unlimited everything (and apparently not throttled), is $70. There is also an Unlimited-but-throttled plan (5gb @ 4g, the remaining at 3G), with unlimited text and 100 minutes of talk: that's only $30.
  I live in a medium sized town (about 80,000 people, next largest town is 25 miles away and smaller), and I have decent 4g coverage. No problem streaming videos on Netflix.
  Plan chart:
  http://prepaid-phones.t-mobile.com/monthly-4g-plans
  
  --
  What changed under Obama? Nothing Good
2. Re:Can't make it slow if you can't get it by anagama · 2012-02-19 07:20 · Score: 1
  
  oops, wrong -- the $70 plan is throttled after 5gb.
  
  --
  What changed under Obama? Nothing Good
Could have told you that... by aaronb1138 · 2012-02-18 13:50 · Score: 5, Interesting

It is nice to see that there is an actual effort to make an empirical test, but I think most techies had this figured out long ago. The simple test is boot time on the devices. A relatively small OS which typically takes 2+ minutes to cold boot, yeah sounds like a storage issue.
Fixing the issue with some form of data striping would be attractive, but chews battery for each additional chip. Some kind of balloon-able RAM buffer configuration would work nicely, where the buffer RAM was turned off when the device was not in active use or where individual modules could be brought online as needed.
Frankly, Microsoft pointed at flash as being a speed culprit early on with their requirements for WP7 phones for add-on, non-removable storage expansion micro SD cards. Sure there were a lot of people all gruff and bemoaning the double price premium for Microsoft certified micro SD cards, but it was mostly just a lack of understanding of the needs for device performance. If I recall correctly, Microsoft had somewhere around 10-12 MiB/S read and write and I/O per S requirements which put most cheap commodity flash modules out of the running. I would also guess that WP7 stripes data between the on board and add-on SD card or otherwise uses some kind of secondary caching algorithm since the micro SD cards get married to the device.
In the Android world, plenty of RAM cache hacks have been implemented, most notably some in Cyanogen and similar. Consider the technical implications of this post at XDA forums regarding I/O schedulers: http://forum.xda-developers.com/showpost.php?p=22134559&postcount=4
As an anecdote, the most frequent crashy app on my Android device is the Gallery. It tends to have all kinds of issues with the scheduler as it is reading images and creating thumbnails, likely due to flash access speeds.
1. Re:Could have told you that... by Anonymous Coward · 2012-02-18 14:06 · Score: 2, Informative
  
  Your app does not crash because of flash. Your app crashes due to shit coding.
2. Re:Could have told you that... by DigiShaman · 2012-02-18 14:18 · Score: 1
  
  Posted as AC obviously. Because your comment is based on so much ignorance of hardware that I dare say in fact you're trolling!
  
  --
  Life is not for the lazy.
3. Re:Could have told you that... by SuperMog2002 · 2012-02-18 17:10 · Score: 1
  
  What devices are you cold booting that take 2+ minutes?
  
  --
  Sunwalker Dezco for Warchief in 2016
4. Re:Could have told you that... by the_B0fh · 2012-02-18 17:50 · Score: 2
  
  A correctly written app should not crash, if the hardware and OS is working correctly (even if slowly).
5. Re:Could have told you that... by BitZtream · 2012-02-18 18:22 · Score: 1
  
  While I agree with you, I would like to point something out.
  
  The simple test is boot time on the devices. A relatively small OS which typically takes 2+ minutes to cold boot, yeah sounds like a storage issue.
  If it takes 2+ minute to boot, its not a small OS, even on flash. I think we underestimate just how much crap we're asking these devices to do.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
6. Re:Could have told you that... by mlts · 2012-02-18 18:43 · Score: 1
  
  For Android devices, it isn't speed that is an issue, but capacity. Right now, the largest MicroSD card that I can find for an Android phone is 32 gigs. A 64GB card was announced last May, but still is vapor.
  I'd like to see an Android phone that can step up to the plate and keep competitive with the iPhone 4S on this front. At the minimum, add another SD card, so apps that can point to a storage place other than /sdcard or /mnt/sdcard can use it.
7. Re:Could have told you that... by DigiShaman · 2012-02-18 18:52 · Score: 1
  
  That's impossible. If you have a failing CPU, your app will crash as might the OS too. Software is nothing more than a binary set of instructions. It's up to the hardware to both execute instructions and store/read data properly. Built-in software based CRC checking will only get you so far. Failing hardware will ultimately trump any redundant code you have written.
  
  --
  Life is not for the lazy.
8. Re:Could have told you that... by Threni · 2012-02-19 07:02 · Score: 1
  
  I sometimes wonder what's happening when a machine takes 2 mins to boot, copy a file etc. 2 mins nowadays is billions of operations, and/or gigs (or hundreds of megs) of data transfer. It's impossible to justify either. There must be some screwed up crap going on somewhere where loading the OS is seen as some sort of edge case unworthy of optimising.
9. Re:Could have told you that... by Anonymous Coward · 2012-02-20 03:10 · Score: 0
  
  Which has absolutely nothing to do with what the parent post said.
  "A correctly written app should not crash, if the hardware and OS is working correctly (even if slowly)."
  By definition a failing CPU is not working correctly.
10. Re:Could have told you that... by the_B0fh · 2012-02-21 10:49 · Score: 1
  
  How is a failing CPU equivalent to "if the hardware and OS is working correctly"?
  I stand by my original statement.
I beg to differ... by Anonymous Coward · 2012-02-18 14:38 · Score: 0

I don't doubt that NAND flash slows the theroretical performance of of my iPhone. Indeed their efforts seem to be soundly arguing that there is a memory bottleneck on my phone. Still, when my connectivity via 3G AT&T is marginally better then a satellite connection, and is decimated by AT&T's home broadband via wifi (or COX cable via wifi); it is obvious my true bottleneck is AT&T's failure to upgrade their wireless network. Please do not allow this as an arguement in court for anyone sueing AT&T for their failure to provide adequate service.
Thank you,
Nexion
Gee storage is a bottleneck by Osgeld · 2012-02-18 15:39 · Score: 4, Insightful

Isn't this true with any computer system since the dawn of computers?
from plugging in jumper wires to transfer a program from paper to memory, to tape streamers, to magnetic disks, to flash the slowest thing for a computer is its mass storage, always has been, and will continue to be for a very long time
O RLY? by Anonymous Coward · 2012-02-18 16:53 · Score: 0

So the reason all my web pages load slowly on sprint 3g is because...the web browser uses flash???
Well now I feel stupid for thinking it was the ~60kbit data network rate that it's pulling...
1. Re:O RLY? by EzInKy · 2012-02-19 02:32 · Score: 1
  
  Yep, even if your data arrives ahead of the stream your program will be considered a putz if its output isn't displayed instantanously!
  
  --
  Time is what keeps everything from happening all at once.
So Steve Jobs wasn't railing against Adobe Flash? by hobb0001 · 2012-02-18 16:55 · Score: 1

Things would have been a lot less tense if he had clarified.
Can anyone explain by geekprime · 2012-02-18 20:48 · Score: 1

Can anyone explain why it is that my desktop PC with 6 gb of ram and a 1 tb hard drive can actually CLOSE a program when I exit it but my smartphone with a 1ghz processor and 1 gb of ram for memory and storage total keeps every damn program running forever?
Who's idiot idea was this anyways?
1. Re:Can anyone explain by Osgeld · 2012-02-18 21:11 · Score: 1
  
  Jobs
  in the mac world when you close an app it doesn't exit, its actually really handy when your running on a slow computer but it was at best cute in 1999 on osX beta +, back when it took a semi significant amount of time to launch a program and its idol resources was low
  now your smartphone rivals a early 2000's deskrop so its really useless
2. Re:Can anyone explain by Anonymous Coward · 2012-02-19 06:59 · Score: 0
  
  That is definitely some misinformation.
  - Windows Mobile did this before the iPhone was ever introduced. See this post in 2006: http://blogs.msdn.com/b/windowsmobile/archive/2006/10/05/the-emperor-has-no-close.aspx
  - The Mac still quits apps even to this day, although there is a disconnect between a window closing and the app closing, unlike early Windows there was no 1:1 connection between app and document. In current Windows, it can be 1:1, but not always. However, OS X does include caching mechanisms (dynamic-linking cache for example) which speed up launching of apps by pre-computing where libraries need to go and what goes into the various import tables.
  And there is one major difference between a 2000s desktop and your smartphone: I don't run a desktop on a 1000mAh (roughly) battery. So power consumption has become a hot-button issue as more CPUs are being used in laptops and cell phones that rival desktops from a decade ago.
  Consider this: RAM is always powered while the machine is on. If I disconnect power to it, I lose the contents. So even in the best case, I can maybe turn off a couple cells to save battery, although I take a performance hit if I do when I have to power those cells back on. So because of RAM, I'm always spending some amount of power to keep RAM powered. But every time I need to go out to NAND to load software, that's additional power on top of RAM. I can also shut down the NAND or put it to sleep more often and for longer to conserve battery. So instead of letting RAM sit idle, empty and consuming power, leveraging it as a cache for flash is a way to save battery. One of the easiest ways to do that in an environment where users switch between apps often is to keep the apps themselves in RAM and hit your slower storage less. But managing that isn't something a user is terribly efficient at on their own. They can tweak for speed a bit better (knowing the future better than the device can), but in general you will get more wasted power that way. It's a trade off of higher power efficiency at the cost the user being able to do things like pre-load apps they will use in a minute or two.
Bad programming? by drolli · 2012-02-18 21:12 · Score: 1

using SQLITE for every operation is for sure convenient, but is it efficient? I have seen weird performance issues when in principle small data structures maintained using sqlite exceeded certain bounds.
It is the task of the programmer to distiguish between data which should be kept in ram and data which can be written to flash.
1. Re:Bad programming? by 21mhz · 2012-02-19 03:23 · Score: 1
  
  I've seen how this happens:
  1. Gee, I can just fire INSERTs in SQLite like I did in SQL Server, isn't it convenient?
  2. (few months in development) Crap, these queries thrash the flash medium and cause a lot of waiting on I/O, we need to batch them and use transactions more.
  3. (with deadlines looming) Attempts to tweak the database access flags or even relax the durability requirements, to get out of the corner we have painted ourselves into.
  It would be instrumental for better performing code if database access was always treated as slow and therefore asynchronous, but SQLite does not provide an easy-to-use async API.
  
  --
  My exception safety is -fno-exceptions.
2. Re:Bad programming? by drolli · 2012-02-19 03:40 · Score: 1
  
  Yes. Thats how is see it. Accessing a database in a syncronous way is always adding something very intransparent to your program. In one moment it runs fast, in the next when the moon hits the right position some kind of resource which you don't even think you use is busy......
Wow. by Anonymous Coward · 2012-02-19 03:09 · Score: 0

1) This isn't about "smartphones," it's about Android devices. On iOS devices, there's just one big chunk of flash storage; the user can't install an SD card.
2) Battery life, network latency, and network reliability are much bigger factors in poor user experiences.
3) On iOS, not only does Core Data (which uses SQLite) aggressively keep data in RAM, as of iOS 5, it can easily be used to do non-blocking, asynchronous reading and writing to disk with UIManagedDocument.
1. Re:Wow. by Anonymous Coward · 2012-02-20 05:46 · Score: 0
  
  Embedded card, dummy. That means INTERNAL MEMORY, or in your words the "one big chunk" you get with the bare phone.
In other news... by Anonymous Coward · 2012-02-19 10:01 · Score: 0

the sky is blue. Anyone with a rudimentary knowledge of computing already knows this.
Windows CE 2003... by WaffleMonster · 2012-02-19 12:19 · Score: 1

I remember with the old versions of windows CE it was basically like knoppix with a fused file system to ram. If the devices battery died or the OS crashed all of your data went with it. They had a separate backup battery but obviously this didn't stop your data from disappearing on a regular basis. One thing I loved about the platform between XIP and your data in ram all file operations at least were instantaneous no delay and no worries about burnt out flash.
Given the capabilities of modern hardware it is a bit sad to see quite a bit of capability wasted due to laziness all-around. Caches, ram disks..etc help but really are not the answer. The applications data tier need to be smart enough to at least minimize random writes even if that means giving up some level of reliability in persistant storage. Browsers will still work just fine if the device crashes in the middle of setting a cookie. Make it part of the platform/APIs so developers have access to the best tradeoffs.
1. Re:Windows CE 2003... by aaronb1138 · 2012-02-19 15:16 · Score: 1
  
  That brings me back. Yes Windows CE PDAs were way more responsive than current era smart phone OSes. In fact, after my first smart phone purchase of a used G1, followed by a Galaxy S (Vibrant) I could never understand why they were less responsive than my father's ~2002 Toshiba e740. I just kept thinking to myself, the resolution is doubled, but the only additional processes are for Bluetooth and cellular radios which have their own processor. But yeah, when CE took a dump, you lost it all. Also, there were not effective means of backing up the current running OS, you always lost some of it during a hard reset.
  For those bringing up the "bad programming" argument regarding the Gallery in Android. I agree wholeheartedly, but these issues are part of the Android framework, to not make developers write their own data queues and be able to trust the running OS. This works the vast majority of the time, but when it breaks, it breaks hard.
  I do agree that developer reliance on SQLITE in Android is an issue. But in my fantasy world the whole smartphone OS, applications and everything between would be written in C with heavy compiler optimizations in assembly for each given CPU. Maybe the API framework in C++ with a lean widget framework (Qt?), but hey I believe in hardcore optimization and programming. This would fly in the face of the smart phone programming paradigm of cheap, RAD models where programmers do the very minimum to get their programs running, so they can produce a few programs a month at $0.99 per license and fix a few bugs. Yes in my fantasy smart phone world, you would buy 2-3 suites for $15-50 which would do everything except games you could possibly want, and never be looking at buying a dozen $1-3 apps to each do some small part of what you need your smart phone to do. Yes, in real life, I get along better with the C89 / C99 and Fortran guys a lot better than the Java and Python guys, it's just my style.
legislation and free market by electrosoccertux · 2012-02-19 12:29 · Score: 1

At some point in the future your legislation would be a good thing but for now the only reason AT&T has dumped ~$10B into upgrading their network in the last 6 months to a year is because there are people willing to pay the $80/month.
Once we hit LTE-Advanced (1gbit/s from tower to stationary devices...shared between all devices but 1gbit/s between 250 devices is still 4mbit/s which is plenty fast for even HD netflix) we'll see the return of unlimited data, until then these $80-100 plans are financing the rapid progression towards this cellular singularity.
Class10 vs Class4 ( 45 vs 1800 IOPS) by oernii · 2012-02-20 19:52 · Score: 1

Well, I just tested my class10 microSD and it has 45 IOPS !! Lucky me, I bought a class4 microSD which has 1800 IOPS and boy, can I feel the difference. PS: My disk has 200 and my SSD has 14000 iops.