Smartphone devs, yes SD card speed matters!

If you want to get the highest performance out of your SD cards then read on. The purpose of this article is to raise awareness and spark your curiosity about SD card performance considerations.

Micro SD Class 2

Many developers I talk to aren’t aware that the read/write speeds of SD memory cards can have a significant affect on performance. This is especially true if you are moving around lots of data between a smartphone and the SD card. The good news is there is quite a bit of information out there to help you maximize performance, and a lot of it comes from high-end, camera aficionados believe it or not.

The most common feedback I get is developers typically buy cards with the most capacity at the lowest price. Depending on what you are doing, cheapest and slower isn’t always better. With little bit of research your read/write performance could get significantly better.

To start with there are four common speed classes: 2, 4, 6 and 10 and they represent an approximate minimum performance rating. You can find this number on the front of your card:

  • Class 2 ~ 2 Mbytes/sec
  • Class 4 ~ 4 Mbytes/sec
  • Class 6 ~ 6 Mbytes/sec
  • Class 10 ~ 10 Mbytes/sec

Read/write performance to your phones SD card really depends on HOW your application reads and writes data. You may have to do some testing to find out what works best. It depends on the consideration of multiple factors including:

  • Typical file types (e.g. video vs. text vs. image, etc)
  • Average file or data transaction size
  • Percentage of reads to writes
  • Duty cycle (percentage of reads or writes over a fixed time period)
  • Usage pattern

Usage pattern deserves a bit more attention and really starts to tell the story of what your application does behind-the-scenes. I think the best way to describe it is through some common use cases:

  • Many small reads and writes to/from a local database.
  • Occasional small reads and writes to local database.
  • Occasional large reads from local database.
  • Occasional large reads and writes to/from local database.
  • Large read upon application startup and large write upon application shutdown.

Wikipedia has noted that speed can differ significantly depending on what you are writing to the card. The article notes that writing large files versus writing many small files has widely different affects on performance. I’d seen similar observations when I worked on ultra-high performance server systems. So, the concept still remains today and provides excellent hints on how to tweak every extra millisecond of user experience.

If you need maximum performance then consider reformatting or defragging your card on a regular basis. I know Windows disk defragmenter utilities work on most SD cards, not sure about Mac. I have also seen multiple articles talk about bigger capacity is better because of memory fragmentation. With memory fragmentation, the card speed starts to decrease over time as the data becomes more fragmented. It’s the same concept as when you “defrag” the hard drive on your laptop.

References

If you want to learn more here are some helpful links:

SD Association – Bus speed

SD Association – Speed Class

Wikipedia – Secure Digital (See Speed Class Rating section)

Does your camera need a fast SD card? (good insight into SD card speed)

3 Approaches To Mobile – HTML5 Denver User Group Presentation

Tonight I had the pleasure of presenting at the HTML5 Denver User Group. It looked like there was a really good turnout of over 130 people. I followed an excellent presentation on JSON by Tom Marrs. He really dived down into the guts of what JSON is, and I wished someone had done as good of a job explaining it when I was just getting started using JSON.

The concept of my presentation was that there are three main approaches to building web mobile applications: JavaScript mobile, Hybrid and Responsive. By a show of hands it looked like over 50% in the audience were brand new to web mobile and I had planned for that so hopefully the level of content was just right. If you want to discuss any of the content in more detail, feel free to drop me an email.

Here’s a link to a PDF version of the presentation

Going mobile Part 2 – dealing with legacy content

This is part two in my “Going Mobile” series. As some you know I’m migrating my website to work on all smartphones and tablets. It’s been a really fun process, especially since at my day job I usually consult on how to do this. So, it’s been great to actually sink my teeth into my own full-blown project that also includes a content management system.

As I’ve mentioned before, I have almost 100 posts to manage through this transition along with a variety of plugins and hundreds of images. This site is not custom so upgrades and changes should be fairly routine.  What I mean is it’s a fairly run-of-the-mill WordPress installation so there isn’t anything really fancy or complicated about it. And, that’s the way I like it so it just runs itself without much maintenance or intervention.

So, I’m still in the preparatory phase of migrating over to mobile. There’s been a lot more things to deal with than the typical applications that I build. Here are some of the issues I’m working through now:  

Images not optimized for mobile. I have hundreds of images that I pasted into blog posts. Some of these are up to 400 pixels wide, which covers most of the screen for your average smartphone. Perhaps some good news is all of my images are PNG format, but they were intended for use on 1024×768 or greater monitor sizes. Now, if I change the size of these it could affect my default page formatting. I tried to avoid that type of problem in the very beginning in terms of how my images are placed on the page, but we’ll see. I’m still experimenting on what do, and in my estimation it all comes down to performance. If anyone has any recommendations let me know?

Web Server Permissions. My blog hosting provider is fairly strict on the server configurations and the mobile plug-in model requires server-side access. I basically traded some access for massively reliable uptime.  There have been some issues with the mobile plug-in and how it works with various pieces of WordPress, PHP and the web server itself. If you work for an organization with full admin access to your web server then this shouldn’t be much of an issue.

Blog post length. I have some long blog posts that require a bit of scrolling. I don’t know if there is a right or wrong answer on the appropriate length of a non-paginated blog post. Personally, I hate paginated websites and as a default I expect to get the full article. I read a few blogs already on my phone and while I don’t mind scrolling down I’ll have to see what kind of feedback I get from visitors and regular readers.

Cross-browser testing. With my current blog, I’ve never ever had to worry about cross-browser testing. WordPress just works, period. I’ve occasionally received browser-related complaints. However, after some investigation the majority of the complaints were spam emails try to trick you into clicking on a hostile link. Once I get everything up and running I’ve created a simple test sheet with various check-off items to make sure I’m (mostly) comfortable and can sleep at night knowing I didn’t just hose things up dramatically.

Plug-in compatibility with WordPress upgrades. This is a major concern. I like building my own software because I can adapt it to any underlying changes. With a plug-in you are at the mercy of the plug-in vendor and your content management system. My fallback plan for this is I can always disable the plug-in. For now while I’m in the experimenting phase, my blog foundation will remain fixed and designed for 1024×768 content. Ah yes good old 1024×768. So, if I do pull the plug on the plug-in (no pun intended) then in theory everything should revert back to my default theme until I can figure out a fix or move on to a more responsive design approach.