Demo projects used to test startup time between a dagger-based project and a RoboGuice-based project
Java Ruby
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


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.

Dagger & RoboGuice Projects

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.

Build it


Java JDK 1.6+ maven 3+ Android SDK 16+ git

Build dagger

git clone git://

cd dagger

mvn install

Build BaseProject

from BaseProject, run mvn install

Build RoboTest

from RoboTest, run mvn install

Deploy to a connected device with mvn android:deploy

Build DaggerTest

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.