Ouch, VS 2005 B2 Device Emulator is SLOW so here are some hints to make your mobile dev on VS2005 bearable again!!


Well I attended MEDC in Melbourne this week, a great event, there was lots to learn and if you made it along then hopefully you’ve walked away with some interesting ideas for future mobile projects.


For me the “Messaging & Security Feature Pack for Windows Mobile 5.0” is a huge step to securing a device and it’s contents should a device be lost or stolen; auto or remote data deletion etc…  I think this feature pack and the integration with Exchange SP2 will go a long way to driving Enterprise adoption of mobile devices and create a great opportunity to build and sell apps to this market.


Now may be I’m being too precious but for those who saw the demos at the Oz MEDC then you will appreciate that the new ARM Emulator provides a very high fidelity emulation experience but it also brings a whole new meaning to the word “SLOW”. 


Yup it’s all BETA but for now it’s almost too slow to make it practical for all but the simplest of apps.  You might want to check out Rick Strahl’s blog, basically a similar theme.


So given I too will be showing this stuff off then I decided to do a bit of investigation as to how to get dev and text performance to an acceptable level that wouldn’t leave me feeling completely embarrassed and bringing out my travel photos to play for time.  So here’s where I got to:-


1)      Don’t do this stuff in a VPC.  Yup, it works, but an emulator in an emulator just isn’t going to fly and it doesn’t!!


2)      Install VS2005 B2 on your base system if you can, from my experiences it sits happily with VS2003;l though a caveat, your mileage may vary so in an ideal world keep it separate from your production environment.  The emulator does perform better but it’s still slow.


3)      Hook up a real device to your dev system and use something like Pocket Commander Pro 5.1 from SOTI Inc to see what is happening on the device.  It’s streets ahead of the free Remote Display Powertoy and you’ll be a happier bunny.


I did a very simple timing test across the systems listed below.  I timed how long the app took to load itself and display data from the Nothwind.sdf database.  I pulled all the columns from the Customers table (91 records) and columns from the Orders table (1078 records) in to a dataset and bound the data to 2 grids with a parent child relationship running on V2 of the compact framework.  This is what I got:-



  • Emulator running natively on Windows XP 3.2 HT GHz, plenty of memory: test took 46 seconds
  • HP Hx4700:test took 8 seconds
  • HP H4150: test took 12 seconds

The ARM Emulator is BETA and can only get better, it’s no doubt a very challenging project, so my intention not to knock the work the emulation team is doing!!


My main message is don’t be put off from trying out the compact framework, native performance is very acceptable, the dev environment is awesome and stable, the snap to UI designer is very cool and makes building a well laid out UI, ummm, well a snapJ


PS, In reality I’d not do this example using Datasets, I’d do with SQLResultSets (I’ll blog this in the next few days), data access using SQLResultSets flies!!


VS 2005 B2 provides the following compact framework support



  • Pocket PC (and Phone Edition and inc Windows Mobile V2): Fx V1 and V2
  • Smartphone 2003 (SE): Fx V1
  • For Windows Mobile V5 Smartphone:  Fx V2 is supported; you can get the SDK from here.

LOL, I needed a stopwatch to do the timings for the above test (as wanted load and execute times), so I wrote my own for the iMATE SP3i Smartphone, when tidied up I’ll post the source code somewhere.  I used VS2005 B2 targeting V1 of the Compact Framework, the whole dev environment is robust and a pleasure to use.  Ahhhh and best of all you can create a Smart Device Cab Project from inside Visual Studio and build and deploy your CAB file.  A great step forward from the creaking Smartphone dev environment you get with VS2003.


Cheers Dave


 

Comments (4)

  1. Rick Strahl says:

    Dave,

    Word is that the team obviously knows that the emulator is slow, but also that isn’t going to get drastically better at least not for Whidbey release. I’ve been doing a few sessions demonstrating and working on my hand puppet tricks to keep people entertained while waiting to step through some code. The worst perf is in Web Service access…

    This is not what I consider an improvement – yes the new emulator is nice with full activesync support, but if it’s too slow to do development work who cares? <g>

  2. Mark Colburn says:

    The Device Emulator currently runs about the same speed as a 200 MHz hardware device when running on a 1 GHz machine. However, the performance of the emulator is highly scenario-specific, and we never did any performance testing on Web- or SQL-specific scenarios.

    During the Beta 2 timeframe, we worked on a set of NET CF-specific timing scenarios and we were able to improve the performance in those scenarios from roughly 10-300+%.

    The emulator team is very small and has been focused on getting a very high-fidelity and high-quality release out for Visual Studio 2005. Due to time and resource constraints, the team did not focus on performace in this release unless it was a blocking issue.

    For many scenarios the current performance is "good enough." Performance will be a primary focus for the next release of the emulator, and we believe that we can significantly improve the performance of the emulator in the future.

    Mark Colburn

    Senior Program Manager

    Visual Studio Core

    (Emulator and Core Communications)

  3. Dave Glover says:

    The Pitfalls with the new Device Emulator (in Beta 2)

    Check out this blog item http://blogs.msdn.com/mszcool/archive/2005/09/07/461691.aspx

    cheers, dave

Skip to main content