Doing so significantly improved our locking times; in comparable scenarios, it dropped from 53 minutes of locking time on com.cognitect.transit.impl.Cache to 1 minute and 30 seconds.
I think if we can improve this locking block, maybe replacing it with a ConcurrentHashMap or something else that avoids global locking, we may be able to improve transit performance in high concurrency scenarios.
Hello,
During a performance tuning task, we notice a high locking time on
com.cognitect.transit.impl.Cacheduring service startup.I tracked it down to this code snippet: https://github.com/cognitect/transit-java/blob/8c29b1c0984a8d0bbe5bc1a5375216a4ff0a37ac/src/main/java/com/cognitect/transit/impl/WriterFactory.java#L27-L33
Without changing the library itself, I wrapped our write handlers here with a
WriteHandlerMapclass to avoid that block, getting into this code path instead: https://github.com/cognitect/transit-java/blob/8c29b1c0984a8d0bbe5bc1a5375216a4ff0a37ac/src/main/java/com/cognitect/transit/impl/WriterFactory.java#L23-L24Doing so significantly improved our locking times; in comparable scenarios, it dropped from 53 minutes of locking time on
com.cognitect.transit.impl.Cacheto 1 minute and 30 seconds.I think if we can improve this locking block, maybe replacing it with a
ConcurrentHashMapor something else that avoids global locking, we may be able to improve transit performance in high concurrency scenarios.