This project was created to compare start and injection times required to support dependency injection with both the RoboGuice and dagger DI libraries.
One base project defines 30 interfaces and 29 implementations, each injecting the next. This leads to a linear chain of dependencies, 30 classes deep. At this time there are no circular dependencies or other complexities in the dependency tree. The 30th implementation is left for consumers to define, though the dependent implementation requests injection from the base project.
The other two projects are implemented with the same functionality using different DI libraries. RoboTest uses RoboGuice 2.0 and Dagger uses the latest dagger implementation.
Java JDK 1.6+ maven 3+ Android SDK 16+ git
git clone git://github.com/square/dagger.git
cd dagger
mvn install
from BaseProject, run
mvn install
from RoboTest, run
mvn install
Deploy to a connected device with mvn android:deploy
from DaggerTest, run
mvn install
Deploy to a connected device with mvn android:deploy
RoboGuice, as expected, has a larger start up cost due to its run-time module executing and binding validation. Dagger does its validation at compile time, removing nearly all of that cost at start up.
Running the built APKs from this source gets the following results:
- DaggerTest: 62ms average start up time with 16 runs.
- RoboTest: 403ms average start up time with 16 runs.
Additional profiling found that setContentView takes ~35ms for both applications with onCreate using up the remaining time. So operating under the assumption that onCreate is only spending time instantiating and providing / injecting objects:
- dagger: ~25ms
- RoboGuice: ~365ms
Keep in mind that RoboGuice is preparing itself to provide much more than the 30 classes we've defined for this test (services, contexts, etc.), so this isn't quite an apples to apples test; more of an apple pie to apples comparison. Perhaps a Guice vs. Dagger comparison would be more apt, but until we have a RoboDagger (sounds painful), this will have to suffice. That said, I've done profiling of RoboGuice and its initialization cold start is a direct result of its use of Guice. That 400ms startup cost can be traced to Guice's module execution and binding validation, not the RoboGuice code that wraps it.