MvvmCross: IoC and ServiceLocation performance

Question

I've had a look at the article http://slodge.blogspot.co.uk/2013/06/ioc-and-servicelocation-in-v3-brain-dump.html about "IoC and ServiceLocation in v3".

Everything's clear there. However, what's about this logic performance? As usually Reflection is used for such types of stuff (I assume MvvmCross does it as well). And everyone (at least, more or less experienced developer) knows that reflection is performance's "evil".

So, as I understand, the framework goes through all the classes in app (probably, Core assemply only) and finds the ones which need to be injected etc, right? I am sure that that's ok in small projects and also is not sufficient for such projects like web ones (long time on startup), but what's about Mobile applications (which usually has much more limited processor power and the startup time is critical for users)? Have you had any thoughts on that? How do you evaluate relationship between "convenience of development" and "first time performance reduction" in that meaning?

Thank you.

Answer 1

General answer

The MvvmCross philosophy on performance is:

• we make development more convenient so that developers can make more delightful apps
• we're aware that parts of the platform do add a level of overhead - but we've worked hard to make sure it isn't a large one
• we give the developers tools to build decoupled views, viewmodels and components - we think this allows the developers to write more efficient and more robust components
• because we allow the developers to build decoupled components, then if/when they hit performance problems, then we believe this makes them much more able to optimise where and when they need to.
• because we provide a platform for reuse, we believe developers will be more able to develop and use better components - e.g. because developers can reuse our table/list adapters they don't have to fix and optimise new table/list adapters in every single app
• we've worked hard to make sure almost everything can be overridden in the platform so that you can optimise later if you need to - if your app wants to hand-tune IoC registration it can - your app doesn't have to use reflection.
• we think that .Net (both Microsoft and Mono versions) also helps with making apps more performant through:
  • efficient memory management
  • libraries like linq and the TPL
  • the TPL coupled with compiler tools like await/async
  • providing native access via PInvoke when needed

Of course, if you absolutely need to hit some <200kB package size limit you won't be able to use MvvmCross; and, of course, even with the best tools in the world, developers can still make badly-performing apps... but we position MvvmCross to help good developers make delightful cross-platform apps.

---

Technical points

limited processor power

A modern mobile platform has:

• 2 to 8 CPU cores, each running at > 1GHz
• 1+GB of fast RAM
• 16+GB of very fast storage (Flash)

This is hardly limited - it's faster and more powerful than PCs were 10 years ago.

---

everyone ... knows reflection is performance's "evil"

Sorry - I don't think you are correct.

The people I work with are aware that Reflection introduces a small overhead, but it doesn't dominate our performance considerations.

I agree more with Donald Knuth who said:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"

From http://en.wikipedia.org/wiki/Program_optimization

This is especially the case in apps/projects/products which have many releases - in tightly coupled projects small optimisations created for v1 can often cause serious performance issues by the time you reach v10 or v11 where changes in the platform cause the 'old code' to be executed in 'new patterns'.

---

If anyone is really into micro-optimisation, then it's also worth noting that MvvmCross uses things like lots of methods marked virtual, lots of small interfaces/objects and string formatting using "{0}{1}" type patterns - all of which could be optimised if anyone really wanted to.