Background
Previously, I posted a density plot that demonstrates how MIDlet market share changes as a function of handset heap memory and performance (as measured by the JBenchmark 2 score).
In this post I provide a visualisation showing how market share has changed over time.
Visualisation
The video, below, shows how performance is improving over time.
The video shows how application market share is affected by heap and performance. Each frame is based on one year's worth of data, up to, and including the month shown. For this reason, there is a large amount of noise in the early frames as there were very few MIDP 2 handsets in 2004.
To obtain a very large market share (90+%) of handsets released in 2007, you have to target pretty much the same performance criteria as you did in 2004. In the mid range, handset performance can be seen to be steadily improving.
What Next?
Next, I will run the numbers for Nokia, Motorola, Samsung and Sony Ericsson handsets.
Showing posts with label fragmentation. Show all posts
Showing posts with label fragmentation. Show all posts
Saturday, 11 August 2007
Tuesday, 7 August 2007
A Trip Down MIDP Memory Lane
Changes in MIDP 2 Memory over Time
In this post, I will examine how heap memory has changed in MIDP 2 devices over time. I will also examine the link between heap memory and handset performance as measured by the JBenchmark 2 benchmark. Finally, I will look at why, as developers, we should be concerned with dynamic heap memory in MIDP terminals.
So We Get More Memory in our Handsets, Right?
The following figure shows the maximum heap memory for 609 MIDP 2 terminals with JBenchmark 2 scores over the period January 2004 through July 2007. Note that the memory axis has a log scale in the range 100 KB through 150,000 KB.
As with the performance plots I presented in an earlier post, this graph goes some way to dispelling the myth that all terminals have more memory in 2007 than they did in 2004. In fact, a large number of terminals are still being released into the market with a maximum heap of less than 1 MB. Indeed, it is astonishing that at least two 2007 vintage terminals report as little as 180 KB heap.
MIDP 2 Heap Memory Percentiles
Once again, from a developer perspective, heap memory percentiles are far more valuable than a scatter plot.
Again, our project manager can use this graph to provide his developer team with a handset terminal matching a required market share for the MIDlet under development. For example, there may be a requirement that the MIDlet address 60% of the MIDP 2 handsets released to July 2007, giving the developers 1 MB of heap at a minimum.
Indeed, a manager might extend this to provide a performance specification based on the JB2 percentile plots I presented previously (the JB2 target for a 60% market share is approximately 100).
Unfortunately, life is not that easy...
The Relationship between Performance and Heap Memory in MIDP Terminals
Our project manager, above, is assuming that performance and memory are ranked equally on MIDP 2 terminals.
The plot, below, shows that (unfortunately) there is no relationship between heap memory and performance as measured by the JBenchmark 2 score.
Rather annoyingly, what this says is if a you choose a 60% market share based off heap memory percentiles, your developers can salivate over a nice juicy 1 MB heap, but they then find that they must target a JB2 score of 38!
Unfortunately, things get even worse.
Dynamic Heap in MIDP 2
Many MIDP 2 terminals implement a memory sharing arrangement called dynamic or adaptive heap. This is where the heap is used for other applications as well as the JVM. What it means for a developer is that a clean handset that is used solely for test and development, may have a heap memory that is not representative of the same handset in the field.
The good news is that the folks at JBenchmark record the minimum and maximum heap seen from a handset under test, and these are from a variety of terminals 'in the wild'. Thus, the range in JBenchmark heap reports is likely to be a good indicator of real world terminal conditions. Maximum and minimum heap from 609 JBenchmark 2 results are shown, below.
Of the 609 handsets used in this study, 252 JBenchmark results (41%) show a difference between the high and low heap memory reported by a handset under test. So, as a developer, if you target a handset with 1 MB heap, and your MIDlet is optimised so that it uses every last byte of this space, you can expect no less than 40% of your terminal market to fail in the field as other applications eat into the precious heap via their shared memory architecture.
In some cases, the heap delta is very significant (the plotted point falls well below the 1:1 line). Of course, this will only be an issue when working with lower end terminals; losing 2 MB of a terminal with a maximum of 8 MB is likely to be far less important to the success of a MIDlet than losing 200 KB from a terminal with maximum of 1 MB heap. Dynamic heap is then an issue developers should be concerned about.
Where to From Here?
In my next post I will finally answer some questions concerning market share by presenting a density plot showing the market share than can be expected from a heap / performance pair.
In this post, I will examine how heap memory has changed in MIDP 2 devices over time. I will also examine the link between heap memory and handset performance as measured by the JBenchmark 2 benchmark. Finally, I will look at why, as developers, we should be concerned with dynamic heap memory in MIDP terminals.
So We Get More Memory in our Handsets, Right?
The following figure shows the maximum heap memory for 609 MIDP 2 terminals with JBenchmark 2 scores over the period January 2004 through July 2007. Note that the memory axis has a log scale in the range 100 KB through 150,000 KB.
As with the performance plots I presented in an earlier post, this graph goes some way to dispelling the myth that all terminals have more memory in 2007 than they did in 2004. In fact, a large number of terminals are still being released into the market with a maximum heap of less than 1 MB. Indeed, it is astonishing that at least two 2007 vintage terminals report as little as 180 KB heap.MIDP 2 Heap Memory Percentiles
Once again, from a developer perspective, heap memory percentiles are far more valuable than a scatter plot.
Again, our project manager can use this graph to provide his developer team with a handset terminal matching a required market share for the MIDlet under development. For example, there may be a requirement that the MIDlet address 60% of the MIDP 2 handsets released to July 2007, giving the developers 1 MB of heap at a minimum.Indeed, a manager might extend this to provide a performance specification based on the JB2 percentile plots I presented previously (the JB2 target for a 60% market share is approximately 100).
Unfortunately, life is not that easy...
The Relationship between Performance and Heap Memory in MIDP Terminals
Our project manager, above, is assuming that performance and memory are ranked equally on MIDP 2 terminals.
The plot, below, shows that (unfortunately) there is no relationship between heap memory and performance as measured by the JBenchmark 2 score.
Rather annoyingly, what this says is if a you choose a 60% market share based off heap memory percentiles, your developers can salivate over a nice juicy 1 MB heap, but they then find that they must target a JB2 score of 38!Unfortunately, things get even worse.
Dynamic Heap in MIDP 2
Many MIDP 2 terminals implement a memory sharing arrangement called dynamic or adaptive heap. This is where the heap is used for other applications as well as the JVM. What it means for a developer is that a clean handset that is used solely for test and development, may have a heap memory that is not representative of the same handset in the field.
The good news is that the folks at JBenchmark record the minimum and maximum heap seen from a handset under test, and these are from a variety of terminals 'in the wild'. Thus, the range in JBenchmark heap reports is likely to be a good indicator of real world terminal conditions. Maximum and minimum heap from 609 JBenchmark 2 results are shown, below.
Of the 609 handsets used in this study, 252 JBenchmark results (41%) show a difference between the high and low heap memory reported by a handset under test. So, as a developer, if you target a handset with 1 MB heap, and your MIDlet is optimised so that it uses every last byte of this space, you can expect no less than 40% of your terminal market to fail in the field as other applications eat into the precious heap via their shared memory architecture.In some cases, the heap delta is very significant (the plotted point falls well below the 1:1 line). Of course, this will only be an issue when working with lower end terminals; losing 2 MB of a terminal with a maximum of 8 MB is likely to be far less important to the success of a MIDlet than losing 200 KB from a terminal with maximum of 1 MB heap. Dynamic heap is then an issue developers should be concerned about.
Where to From Here?
In my next post I will finally answer some questions concerning market share by presenting a density plot showing the market share than can be expected from a heap / performance pair.
Subscribe to:
Posts (Atom)