0

Many people on Stackoverflow and elsewhere point out that Dagger is the preferred dependency injection framework:

But how much faster is Dagger in practice when run inside AWS Lambda or other serverless equivalents? Are there hard numbers available somewhere to help developers reach a concrete decision?

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470
JonathanReez
  • 1,559
  • 3
  • 21
  • 37
  • 1
    Speed is rarely an interesting metric for a DI framework. The only scenario where I've realistically heard talks about performance is on android where you want the UI as snappy as possible. I would completely ignore the performance side if you're choosing a DI framework. Dagger has one objetive advantage on Guice/Spring which is compile time validation of your bindings. And some downsides which come from that. – al3c Mar 03 '20 at 13:50
  • 1
    @al3c presuming that my code is tested in a Continuous Deployment cycle and runtime issues can be discovered before reaching the customers, are there any other benefits to Dagger? – JonathanReez Mar 03 '20 at 18:42
  • I recommend you focus on cold start times if using lambda. In our particular case, we started building lambdas using Spring IoC because there was an existing codebase we needed to reuse. When we looked at performance more closely, we found there were tens of thousands of objects being created on startup and it was adding more than 20 seconds to cold start time. With micro services there shouldn't be a lot more objects created on later invokes. I believe either Dagger or guice should reduce this dramatically, although I have no numbers to share. – mojoken Jun 24 '23 at 00:33

1 Answers1

3

One of the original talks about Dagger2 specifically calls out performance on the server as being improved, see https://youtu.be/oK_XtfXPkqw?t=1564 (link should take you to 26:04 in the video where this is first discussed). The cost in this case is around the object graph required per request. Typical server setups tend to wire up their main object graph for handling requests once, but this part of the talk specifically mentions per-request graphs on a long running service.

On the other hand, AWS Lambda is not for long-running servers, but for short-running tasks (not unlike android apps), so keeping startup time to a minimum to create your object graphs may well make sense.

More performance discussion operating on the server, later in the same talk https://youtu.be/oK_XtfXPkqw?t=2121 (timestamp 35:21) - the quoted figure for their server time saved is 13% over tools that rely on reflection. Seems worth considering - but you'll have to measure your own gains to be sure.

Colin Alworth
  • 17,801
  • 2
  • 26
  • 39