You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at a GeoTools benchmark lately I've found this stack trace reducing scalability, to the point that the application (map rendering) can only use 80% of CPU. Here is the trace involved, exported from the Yourkit profilter:
As far as I can see, the computation of ProductUnit hash code is considered expensive, and is thus memoized, but in a lazy way, using the Lazy class. The scalability issue comes from Lazy.get(), which adopts a synchronized block around the entire lazy loading:
I'm wondering, is that necessary? Or would it be ok to just allow the hash code to be computed eventually multiple times in parallel, but let the check for an already computed value free of synchronization? It may not be a general solution for all cases where Lazy is used, but seems to be useful for an operation that (should) lacks side effects and it's not massively expensive, like the computation of a hash code.
The text was updated successfully, but these errors were encountered:
I believe you cannot shortcut this sort of synchronization necessary here. But perhaps you can provide a code snippet to clarify what you have in mind and convince me otherwise.
Alternatively, perhaps you can do some performance tweaking to your org.geotools.referencing.cs.DefaultCoordinateSystemAxis.hashCode() such that it does not depend on the underlying indriya object's hash codes.
Looking at a GeoTools benchmark lately I've found this stack trace reducing scalability, to the point that the application (map rendering) can only use 80% of CPU. Here is the trace involved, exported from the Yourkit profilter:
As far as I can see, the computation of ProductUnit hash code is considered expensive, and is thus memoized, but in a lazy way, using the Lazy class. The scalability issue comes from Lazy.get(), which adopts a synchronized block around the entire lazy loading:
https://github.com/unitsofmeasurement/indriya/blob/master/src/main/java/tech/units/indriya/internal/function/Lazy.java#L71
I'm wondering, is that necessary? Or would it be ok to just allow the hash code to be computed eventually multiple times in parallel, but let the check for an already computed value free of synchronization? It may not be a general solution for all cases where Lazy is used, but seems to be useful for an operation that (should) lacks side effects and it's not massively expensive, like the computation of a hash code.
The text was updated successfully, but these errors were encountered: