Performance improvements using an annotation processor

[stephanenicolas]

Hi @beworker,

congratulation for this project and being referenced on Android Weekly.

I looked at your source code and it looks like you are using a lot of reflection to discover the methods that are annotated to subscribe to or produce events (in https://github.com/beworker/tinybus/blob/master/tinybus/src/com/halfbit/tinybus/ObjectMeta.java).

You could actually get some performance gains by using an annotation processor to detect all such methods at compile time and get references to them. Thus you would not need to scan the classes, you would know in advance where such methods are in a given class.

You can find an example of such an annotation processor in :

• blender, currently a fork of guice available here : https://github.com/stephanenicolas/guice/tree/blender-PR-2

if you need more high level explanations, please refer to these slides :
https://speakerdeck.com/stephanenicolas/blender-boosting-guice-with-annotation-processing

[sergejsha]

Hi Stéphane,

Thanks for your request. I have already thought about this option and here is what I came to. There are three main operations to be implemented.

1. Find all subscriber and provider methods of all registered callback objects.
2. Find all callback objects registered for a particular event.
3. Dispatch an event to all registered callbacks.

Operation 1 can be optimized by using annotation processor. At the same time this is one-time operation. It's executed only once, when a callback is registered for the first time. The possible performance gain can be only expected on application start-up, which is not bad.

Operation 2 cannot be optimized due to dynamic nature of callbacks. Callbacks are registered / unregistered in any sequence. A dynamic structure similar to the one I use now is still required.

Operation 3 can be optimized by using annotation processor. Generated event dispatch method will contain a sequence of if-else statements calling certain callback's method depending on the event type, which in worst case will have O(n) code complexity. Right now I use a HashMap with quite constant O(1) complexity. I'm not sure whether direct Java calls can compensate much this comparing to a reflection calls I do now.

My conclusion was like this. Before I start to optimized something I need to exactly know where are the bottlenecks. It would be interesting to see some numbers showing slow application start-up or slow event dispatching.

I'm not saying this is not needed at all. Bus as for now, I would say this has lower priority than other tasks.

[sergejsha]

I found some more stuff on this. Jake worked on a AnnotationProcessor for Otto library about two years ago and he stopped to push this branch forward.

https://github.com/square/otto/tree/jw/code-gen/library/src/main/java/com/squareup/otto/internal

There must be some reasons for that. I suspect it's because resulting gain was not worth the effort. But I might be wrong. Let's close this issue for now and once we have a clear need for such optimization we can revisit it and reopen it again.

[stephanenicolas]

I think you underestimate the gain of not using reflection. But nw, it's
your lib. ;)

2014-11-17 14:31 GMT-08:00 Sergej Shafarenka notifications@github.com:

I found some more stuff on this. Jake worked on a AnnotationProcessor for
Otto library about two years ago and he stopped to push this branch forward.

https://github.com/square/otto/tree/jw/code-gen/library/src/main/java/com/squareup/otto/internal

There must be some reasons for that. I suspect it's because resulting gain
was not worth the effort. But I might be wrong. Let's close this issue for
now and once we have a clear need for such optimization we can revisit it
and reopen it again.

—
Reply to this email directly or view it on GitHub
#19 (comment).

[stephanenicolas]

Btw, Jake can be reached if you need to.. you can maybe ping him via the
Otto issue page, talk about your lib and ask why the annotation processor
has been abandoned.

2014-11-17 14:33 GMT-08:00 Stéphane NICOLAS steff.nicolas@gmail.com:

I think you underestimate the gain of not using reflection. But nw, it's
your lib. ;)

2014-11-17 14:31 GMT-08:00 Sergej Shafarenka notifications@github.com:

I found some more stuff on this. Jake worked on a AnnotationProcessor for

Otto library about two years ago and he stopped to push this branch forward.

https://github.com/square/otto/tree/jw/code-gen/library/src/main/java/com/squareup/otto/internal

There must be some reasons for that. I suspect it's because resulting
gain was not worth the effort. But I might be wrong. Let's close this issue
for now and once we have a clear need for such optimization we can revisit
it and reopen it again.

—
Reply to this email directly or view it on GitHub
#19 (comment).