Any systems that is slowed down by ServiceTracker operations has other problems
as well since the service registry was not intended to be used in a way that
service events become a significant part of the CPU time. In general this means
that service events are abused as event mechanisms since it is hard to see any
other reasons why service events would overwhelm a system?
This sounds like one of those things where you can get 200% improvement on the
micro benchmark but don't see any noticeable difference in the whole?
Kind regards,
Peter Kriens
On 9 jan. 2014, at 17:17, Raymond Auge <[email protected]> wrote:
> Recently I've performed some JMH benchmarking on the usecases for retireving
> collections of services.
>
> I discovered that raw usage of the ServiceTracker is in fact very slow for
> most cases due to heavy synchronization (both equinox and felix seem to have
> similar synchronization, although all my tests were actually against equinox).
>
> Has this ever been discussed or reviewed?
>
> It seems that since this is such a core function any improvement here would
> greatly affect/improve performance overall (not that it's really bad...
> except under significant concurrency).
>
> i.e. lock free impl.
>
> Thoughts?
>
> --
> Raymond Augé (@rotty3000)
> Senior Software Architect
> Liferay, Inc. (@Liferay)
>
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
