Performance improvements using an annotation processor about tinybus HOT 4 CLOSED

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.

from tinybus.

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.

from tinybus.

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 [email protected]:

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).

from tinybus.

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 [email protected]:

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 [email protected]:

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).

from tinybus.