Performance comparison of IoC containers under Windows Phone
Good time, dear habrazhiteli!
For a smartphone, the optimality of the application architecture is especially important, so I decided to compare the performance of free and open container libraries available for Windows Phone.
The following libraries have received attention (the most recent versions at the time of testing):
Autofac 2.5.2
Caliburn.Micro v1.3.1 (component SimpleContainer)
Funq 1.0
MicroIoc 1.0
Ninject 2.2.1
Tinyoc
It is noteworthy that TinyIoC is a single source file in C # language (VB is on the way). Its latest version requires a small fix for WP7, otherwise it will produce a compilation error
Solved by simple replacement of the line.
on line
')
All tests were run on a real HTC Titan device running Windows Phone 7.5 in release configuration without a connected debugger and with a full battery charge.
Three interfaces have been announced and their respective implementations. They were registered in the test container: the first - as a singleton (always one copy), the second and the third - as a transient (a new instance is created each time the container is accessed). The first two implementations have constructors without parameters, the third - a constructor with injection of the first two interfaces.
Each interface has been requested from the container 1 million times. Time was measured using Stopwatch in milliseconds.
The time in the table is in milliseconds.
When testing Ninject, it turned out that its response time depends exponentially on the number of hits to it. He makes about 10 thousand permissions of a transient-object tolerably, and on half a million he practically dies just by hanging up the application. Therefore, we had to reduce the number of iterations in the test for it to ten thousand and recalculate the result per one million for comparison with other libraries. However, this fact of special behavior Ninject should be borne in mind when choosing a container.
The most significant is the last column, as the most common in practice. With one call to the Ninject container, the worst result was almost one millisecond. Funq has the best result, which is not surprising, since this is almost the same as calling the new operator.
Despite the high speed of work, Funq has a drawback: when registering, all dependencies will have to be registered manually, which is extremely inconvenient, since will have to rewrite the registration code when updating the object constructor. By the way, this possibility of registration provides and Autofac, but it has not been investigated.
The higher the bar, the more time the container needs to initialize, the worse.
Of course, performance is not the only criterion for choosing one or another container for your project, so here’s a couple of plates with the characteristics of the libraries under study.
If you need broad functionality, the choice is clear - this is Autofac. You will get good performance, but the price for this is the relatively large size of the library file.
If you are satisfied with the availability of simple methods for registering objects and receiving them from the container, then you should pay attention to TinyIoC. This is a small and fast container with standard functionality.
Caliburn.Micro's SimpleContainer also performed well. But you should not use it only for the sake of the container, you have to pay for it with the size of the distribution kit. However, if you plan to use other components of the library, the choice is obvious.
For a smartphone, the optimality of the application architecture is especially important, so I decided to compare the performance of free and open container libraries available for Windows Phone.
The following libraries have received attention (the most recent versions at the time of testing):
Autofac 2.5.2
Caliburn.Micro v1.3.1 (component SimpleContainer)
Funq 1.0
MicroIoc 1.0
Ninject 2.2.1
Tinyoc
It is noteworthy that TinyIoC is a single source file in C # language (VB is on the way). Its latest version requires a small fix for WP7, otherwise it will produce a compilation error
'System.Type' doesn’t contain a definition for the 'FindInterfaces' and no extension method of the 'System.Type' could be found?
Solved by simple replacement of the line.
if (!registerImplementation.FindInterfaces((t, o) => t.Name == registerType.Name, null).Any()) on line
if (registerImplementation.GetInterface(registerType.Name, false) == null) ')
All tests were run on a real HTC Titan device running Windows Phone 7.5 in release configuration without a connected debugger and with a full battery charge.
Three interfaces have been announced and their respective implementations. They were registered in the test container: the first - as a singleton (always one copy), the second and the third - as a transient (a new instance is created each time the container is accessed). The first two implementations have constructors without parameters, the third - a constructor with injection of the first two interfaces.
Each interface has been requested from the container 1 million times. Time was measured using Stopwatch in milliseconds.
results
The time in the table is in milliseconds.
When testing Ninject, it turned out that its response time depends exponentially on the number of hits to it. He makes about 10 thousand permissions of a transient-object tolerably, and on half a million he practically dies just by hanging up the application. Therefore, we had to reduce the number of iterations in the test for it to ten thousand and recalculate the result per one million for comparison with other libraries. However, this fact of special behavior Ninject should be borne in mind when choosing a container.
The most significant is the last column, as the most common in practice. With one call to the Ninject container, the worst result was almost one millisecond. Funq has the best result, which is not surprising, since this is almost the same as calling the new operator.
Despite the high speed of work, Funq has a drawback: when registering, all dependencies will have to be registered manually, which is extremely inconvenient, since will have to rewrite the registration code when updating the object constructor. By the way, this possibility of registration provides and Autofac, but it has not been investigated.
The higher the bar, the more time the container needs to initialize, the worse.
Of course, performance is not the only criterion for choosing one or another container for your project, so here’s a couple of plates with the characteristics of the libraries under study.
findings
If you need broad functionality, the choice is clear - this is Autofac. You will get good performance, but the price for this is the relatively large size of the library file.
If you are satisfied with the availability of simple methods for registering objects and receiving them from the container, then you should pay attention to TinyIoC. This is a small and fast container with standard functionality.
Caliburn.Micro's SimpleContainer also performed well. But you should not use it only for the sake of the container, you have to pay for it with the size of the distribution kit. However, if you plan to use other components of the library, the choice is obvious.
Source: https://habr.com/ru/post/139017/
All Articles