Channels ▼

Avo Reid

Dr. Dobb's Bloggers

Waiting for Moore's Law to Work

January 07, 2011

Reading the "Mobile Web Application Best Practices" a W3C Recommendation from 14 December 2010, I was struck by the similarity of the resource management challenges faced by early Personal Computer developers and those faced by mobile device developers today.Here are some of the best practices for early PC Development that are arguably non-existent today.

Keep programs small (especially true for the Basic Interpreter, and then compiled programs that had to be shipped and installed on Floppy Diskettes. Smaller programs loaded and ran faster. Later with overlay managers it was important to optimize overlay segments for application start-up time.

Use memory very, very efficiently. First there wasn't much of it, and later when there was more, memory management and disk swapping caused performance issues, especially when multiple applications were running.

Keep your code footprint small. Early on this even meant keeping your variable names very terse (x,y,z were good candidates), there were even utilities that would convert your code before compile and reduce your nice long readable variables to terse variants.

Optimize the User Interface to be responsive or at least appear to be responsive to the user. This meant coming up with strategies to improve performance or at least hide slow running tasks, and when all else fails put up the hour glass and appear responsive.

Here are some of the best practices for mobile development from the W3C, "Mobile Web Application Best Practices".

Use Cookies Sparingly - information stored in cookies is sent to the server for every request and so using them for excessive amounts of data can negatively impact performance on a mobile network.

Use Transfer Compression - compression like HTTP 1.1 compression, which uses the gzip and DEFLATE algorithms which are widely supported, reduces bandwidth of each payload and increases transport efficiency. But...decompressing and compressing use up time and battery so this is a balancing act/ Alternative compression formats (such as EXI [EXI]) may be worth looking into.

Minimize Application Data and Size - obviously the smaller the better, faster downloads and execution time.

Minimize Perceived Latency - device limitations can lead to latency in page views, page reloads can frustrate even the most patient user.

As you can see we seem to be faced with similar resource management challenges as those faced by developers of the early PC. But why is this? Are we waiting for Moore's Law to raise all ships in Mobile Bay. Remember Moore's Law?, named for Intel co-founder Gordon Moore, states that the number of transistors incorporated in a chip will approximately double every 24 months. That rate of progress means that the semiconductor industry will far surpass that of nearly all other industries over time, or from the flip side, other industries can't keep up. So the mobile device as a system, with components from several industries, batteries, network towers, displays, is going have resource management challenges and limits to growth directly related to the slowest advancing component.

We saw this with the PC, the integrated circuit was only one component of the overall system. And until recently we had some really, really fast computers with some really, really big monitors, that took up most of a normal size desk, now we have smaller, flatter monitors, we even have entire PC's the size of the old monitors.

The mobile device is more than the integrated circuit and it is experiencing the same disproportionate growth of it's individual components. Although if you look at the first "smartphones" you would have to agree that the iPhone in totality shows an amazing evolution in a short period of time. But you would also have to agree that certain components and sub systems are not as impressive in their rate of advancement and this can be seen in the familiar resource management issues mobile programmers are faced with today.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video