Profiling Modules

[Max Aller]

We're trying to improve performance of our Guice Modules, and to do that
we'd like to figure out how long Guice is taking calling our @Provides
methods. `bindListener` *almost* lets us do that, but it only works for
objects instantiated with Guice, not Guice modules themselves, of course,
and even if that worked, it doesn't surface any timing information. Does
anyone have a clever AOP way figuring out how fast or slow code in
user-specified Modules is taking?

Thanks,
Max

[Stephan Classen]

While Guice AOP is a nice and cool feature and I love to use it for certain use cases I also found that it becomes a performance issue if used to heavely.
Because of this and the limitations you mention in your question I recommend using a classic profiler to investigate performance issues. For a list of populare ones see https://zeroturnaround.com/rebellabs/top-5-java-profilers-revealed-real-world-data-with-visualvm-jprofiler-java-mission-control-yourkit-and-custom-tooling/

Also let me add the following advice:
- keep your modules dumb. Having little to none logic in your guice modules is the way to go. This increases performanc and also helps to reason about what is happening when in your application.
- singeltons are by far the fastest objects to inject. Try to make your dependencies state less and immutable. Then you can turn them into singeltons making them fast to inject.

Good luck. Performance issues can be very hard to track down. But sometimes if you found the bottleneck a small change can make a big difference.

Post by Max Aller
We're trying to improve performance of our Guice Modules, and to do that
methods. `bindListener` *almost* lets us do that, but it only works for
objects instantiated with Guice, not Guice modules themselves, of course,
and even if that worked, it doesn't surface any timing information. Does
anyone have a clever AOP way figuring out how fast or slow code in
user-specified Modules is taking?
Thanks,
Max
--
You received this message because you are subscribed to the Google
Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/3b0a86dc-d1c1-43f6-806d-0694b6c613bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luke Sandberg]

ProvisionListeners should be sufficient for this, though as Stephan says I
would start with abnormal profiler.

Post by Stephan Classen
While Guice AOP is a nice and cool feature and I love to use it for
certain use cases I also found that it becomes a performance issue if used
to heavely.
Because of this and the limitations you mention in your question I
recommend using a classic profiler to investigate performance issues. For a
list of populare ones see
https://zeroturnaround.com/rebellabs/top-5-java-profilers-revealed-real-world-data-with-visualvm-jprofiler-java-mission-control-yourkit-and-custom-tooling
/
- keep your modules dumb. Having little to none logic in your guice
modules is the way to go. This increases performanc and also helps to
reason about what is happening when in your application.
- singeltons are by far the fastest objects to inject. Try to make your
dependencies state less and immutable. Then you can turn them into
singeltons making them fast to inject.
Good luck. Performance issues can be very hard to track down. But
sometimes if you found the bottleneck a small change can make a big
difference.

Post by Max Aller
We're trying to improve performance of our Guice Modules, and to do that
methods. `bindListener` *almost* lets us do that, but it only works for
objects instantiated with Guice, not Guice modules themselves, of course,
and even if that worked, it doesn't surface any timing information. Does
anyone have a clever AOP way figuring out how fast or slow code in
user-specified Modules is taking?
Thanks,
Max
--

You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/EDB9F815-1DDD-4B47-9ACF-71E5048AD102%40gmx.ch
<https://groups.google.com/d/msgid/google-guice/EDB9F815-1DDD-4B47-9ACF-71E5048AD102%40gmx.ch?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Bob Lee]

As others have mentioned, use a profiler. Also, in your log config, try
setting com.google.inject.level=FINE (Guice logs some performance metrics).

Bob

Post by Max Aller
We're trying to improve performance of our Guice Modules, and to do that
methods. `bindListener` *almost* lets us do that, but it only works for
objects instantiated with Guice, not Guice modules themselves, of course,
and even if that worked, it doesn't surface any timing information. Does
anyone have a clever AOP way figuring out how fast or slow code in
user-specified Modules is taking?
Thanks,
Max
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/google-guice/3b0a86dc-d1c1-43f6-806d-0694b6c613bb%40googlegroups.com
<https://groups.google.com/d/msgid/google-guice/3b0a86dc-d1c1-43f6-806d-0694b6c613bb%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.