MvvmCross Performance: IoC and ServiceLocation

Question

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

All clear. However, what about this logical performance? As usual, Reflection is used for these types of things (I assume that MvvmCross does this as well). And everyone (at least a more or less experienced developer) knows that the reflection of productivity is "evil . "

So, as far as I understand, the structure goes through all the classes in the application (maybe only Core assemply) and finds those that need to be entered, etc., right? I am sure that this is normal in small projects, and also not enough for projects such as websites (long time at startup), but as for mobile applications (which usually have much more limited processor power and startup time, are critical for users)? Have you had any thoughts on this? How do you assess the relationship between “ease of development” and “reduced productivity for the first time” in this sense?

Thanks.

Answer 1

Ok After some discussion, I think it makes sense to generalize. I view the answer as:

No performance issues when using MvvmCross in normal applications , however due to the technologies mentioned above in the structure of the structure, and because of the first purpose of this structure was the convenience of development , there is a possibility that the structure of applications, growing , can affect their performance (rather speaking of launching the application). In this case, it is possible to redefine some logic using its own optimized approaches to solve possible problems.

Answer 2

General answer

MvvmCross Performance Philosophy:

• we make development more convenient so developers can create more exciting applications.
• we know that parts of the platform do add an overhead level - but we worked hard to make sure this is not a big one
• we provide developers with tools for building decoupled representations, models, and components — we believe that this allows developers to write more efficient and more reliable components.
• because we allow developers to create decoupled components, and then when they encounter performance problems, we believe that this makes them much more capable of optimizing where and when they need to .
• since we provide a platform for reuse, we believe that developers will be able to more efficiently develop and use better components - for example, because developers can reuse our table / list adapters, they do not need to fix and optimize new table / list adapters in each individual application.
• we worked hard to make sure that almost everything can be redefined on the platform, so you can optimize later if you need - if your application wants to manually configure IoC registration, your application should not use reflection.
• we believe .Net (both Microsoft and Mono versions) also helps make applications more efficient:
  • efficient memory management
  • libraries like linq and TPL
  • TPL combined with compiler tools like wait / async
  • provision of own access through PInvoke if necessary

Of course, if you absolutely must press the packet size limit <200kB, you cannot use MvvmCross; and, of course, even with the best tools in the world, developers can still make poorly executed applications ... but we are positioning MvvmCross to help good developers make amazing cross-platform applications.

---

Technical points

Limited processor power

Modern mobile platform:

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

This is hardly limited - it is faster and more powerful than a PC 10 years ago.

---

everyone ... knows that reflection is "evil"

Sorry - I do not think you are right.

The people I work with know that Reflection introduces a little overhead, but that does not affect our performance considerations.

I agree with Donald Knut , who said:

“We must forget about little efficiency, 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 true in applications / projects / products with many releases - in closely related projects, small optimizations created for v1 can often cause serious performance problems by the time V10 or V11 is reached, when changes in the platform cause the "old code", which will be executed in the "new templates".

---

If someone is really engaged in micro-optimization, then it is also worth noting that MvvmCross uses such things as many methods marked virtual, many small interfaces / objects and formatting strings using patterns like {{0} {1} "- all of which could be optimized if I really wanted to.