4

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.

Agat
  • 4,577
  • 2
  • 34
  • 62
  • 1
    I have used `Caliburn.Micro` in a WP8 app - I haven't really noticed that the startup time was long or annoying. It's a one-time cost on app startup and unless you have a really **huge** project I can't see it being the main performance bottleneck... But you'd have to check for yourself. – Patryk Ćwiek Jun 07 '13 at 15:37
  • 1
    The place for answers is not in the question. You can answer your own question if you need to. – Stuart Jun 07 '13 at 19:14
  • 1
    Two days have passed. Please right down your answer and accept it or accept @Stuart answer. It is quite fully explains your question and doubts, anyway, I have better understanding after reading it. P.S. May be this question is more appropriate to programmers.stackexchange.com – Fedor Jun 26 '13 at 08:13
  • Aha. Well, actually, that was because I've already added the answer, but inside of the question body. So, not sure if I should just copy or move the text. – Agat Jun 26 '13 at 15:26
  • Has moved the answer from the question. – Agat Jun 26 '13 at 17:52
  • The [Help article](http://stackoverflow.com/help/self-answer) and posts at [MSO](http://meta.stackexchange.com/questions/16930/is-it-ok-to-answer-your-own-question-and-accept-it) clearly states that you should write it as a separate answer and accept it. – Fedor Jun 26 '13 at 17:58
  • As I've already mentioned, I'd already changed that. Thanks for the hint! :) – Agat Jun 26 '13 at 19:52

2 Answers2

19

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.

Community
  • 1
  • 1
Stuart
  • 66,722
  • 7
  • 114
  • 165
  • Well, sorry, but your answer looks a little bit like hot fighting against evil conquers. :) Even despite of well-known fact that reflection using is really reduces code performance (sometimes - significantly): http://stackoverflow.com/questions/25458/how-costly-is-net-reflection and also that lots of (not even so old) devices (for instance, the ones for Android Gingerbread) are far not even the ones with 2 Cores processors, my general question was just about your considerations of the performance. – Agat Jun 07 '13 at 16:47
  • I am sure you try to develop more convenience for developers and I absolutely agree you do, but don't really understand why there can not be any considerations of MvvmCross performance. (Even at least, for some people who can take that into considerations *before* starting their development, but not after they start suffering of the application low speed). That was just a question about that. – Agat Jun 07 '13 at 16:54
  • Plus, that's not really correct to compare Desktop processors performance and Mobile devices' ones. As they have different architectures and that's rather like judging cameras shots quality on Megapixels they can output. – Agat Jun 07 '13 at 17:03
  • 1
    **The 2 sentences starting "we've worked hard to..." both give the consideration you are asking for.** However, the truth is that if someone uses MvvmCross, then Mvx will use reflection by default for IoC and for data-binding. They can override most parts of Mvx to avoid some of this, and there are plenty of samples for them to evaluate, but if any use of Reflection at all is an unacceptable performance risk for someone, then MvvmCross is not for them. No one is forcing them to use any higher level platform, pattern or language - they can hand-craft the ARM binary bit-by-bit if they want to. – Stuart Jun 07 '13 at 17:07
  • You are absolutely right about using reflection for databinding. But "reflection" is not only properties calls by their names. So, this is not a talk about "to use reflection or not - that would be silly". That was rather about "How hard can the app launching suffer if the project size grows?". – Agat Jun 07 '13 at 17:13
  • 1
    "How hard can the app launching suffer if the project size grows?" is answered by "almost everything can be overridden ... if your app wants to hand-tune IoC registration it can". This is also in the original blog post - see the paragraph "Alternatively, if you prefer not to use this Reflection based registration" in http://slodge.blogspot.co.uk/2013/06/ioc-and-servicelocation-in-v3-brain-dump.html – Stuart Jun 07 '13 at 17:28
-4

Ok. After some discussion I guess there is a sense to summarize. I consider the answer as:

There are no any problems with performance when using MvvmCross in usual apps development, however, due to mentioned above technologies used in the framework building and because of the first aim of that framework was development process convenience, there is a chance that applications structure growing can influence their performance (rather speaking of the app launching). In this cases there is an ability to override some logic with using own optimized approaches to solve possible problems.

Agat
  • 4,577
  • 2
  • 34
  • 62