This post originated from an RSS feed registered with Java Buzz by Fred Grott. Original Post: Strongest Reason for AndCooper Feed Title: ShareMe Technologies LLC-The Mobile Future Feed URL: http://www.jroller.com/shareme/feed/entries/rss Feed Description: A Weblog about Java programming and digital convergence on mobile devices in such areas as P2P and collaborative technology. Latest Java Buzz Posts Latest Java Buzz Posts by Fred Grott Latest Posts From ShareMe Technologies LLC-The Mobile Future

The strongest reasons for going beyond the Google ADT plugins to a full build system is in this little benchmark from the Dalvik VM on Java Project:

P905i (500MHz - UniPhier 4M + JBlend)
�@Sieve: 1569
�@Loop: 2421
�@Logic: 2251
�@String: 5109
�@Float: 973
�@Method: 830
�@Overall: 1811
Spec sheet:
http://ja.wikipedia.org/wiki/P905i
http://panasonic.co.jp/corp/news/official.data/data.dir/jn080716-2/jn080716-2.html

Google Dev Phone 1 (528MHz - MSM7201A)
�@Sieve: 464
�@Loop: 551
�@Logic: 394
�@String: 491
�@Float: 336
�@Method: 397
�@Overall: 433
Spec sheet:
http://en.wikipedia.org/wiki/Google_phone

P905i (Java Dalvik VM on JBlend)
�@Sieve: 6
�@Loop: 3
�@Logic: 26
�@String: 85
�@Float: 3
�@Method: 6
�@Overall: 9

For those that have not read benchmarks before the higher the number the faster the speed. Notice not only the slower speed but also that there are no outliners in the Dalvik on Android benchmark data. That means that Dalvik VM has optimized duplicate transfer instructions when converting from stack based to register based. Thus a large part of the old J2ME optimization strategies that were base dupon eliminating transfer instructions by changing code structure will not work.

Thus, we need ways to collect certain data about the code so that we can determine some new optimization strategies because the Dalvik platform-independent JIT is still far off at this moment. Well, unless there is an announcement today that I do not know about. Thus it is one of the main drives for the AndCooper project.