Interceptor efficiency regarding ClassMatcher.

[Artem Nakonechny]

Hello.
It there any significant performance overhead if I use Matchers.any() vs Matchers.subclassesOf() in binder.bindInterceptor() ?
I have a small percentage of classes I'd like to apply my interceptor to. I do not very much like introducing a marker interface to use subclassesOf(). So if the overhead is negligible - I'd opt for any().

[Artem Nakonechny]

I use Guice 3.0.

[Tavian Barnes]

You should benchmark this yourself to find out.

Side note, why not Guice 4.0?

[Artem Nakonechny]

I've done some measurements, and it looks the overhead is negligible.
The excess matcher checks happen only once for a class, during the lifetime of the app. So, Guice, does matcher-checks of a class only the 1st time it encounters the class.

Side note, why not Guice 4.0?

Cos we've not migrated yet :) 3.0 works ok for us.

[Tavian Barnes]

On Wednesday, 12 August 2015 19:28:08 UTC-4, Artem Nakonechny wrote:

I've done some measurements, and it looks the overhead is negligible.

That's what I suspected.

 

The excess matcher checks happen only once for a class, during the lifetime of the app. So, Guice, does matcher-checks of a class only the 1st time it encounters the class.

This is true.  The only advantage of a narrower class matcher would be to avoid the reflection that examines the type's methods.  (Or there might be semantic reasons you want to ignore certain types.)  But regardless, once Guice has this information it is kept for the lifetime of your Injector. 

Side note, why not Guice 4.0?

Cos we've not migrated yet :) 3.0 works ok for us. 

I just ask because I believe Guice has gotten much faster in 4.0.  If you're worried about the overhead of Guice it may be worth trying.  I suspect that Guice isn't your main bottleneck though :)