Issue with Eventstream.Subscribe in 2.1.0-RC2
Tested somewhat unscientifically due to lack of profiler etc at home.
Using akka 2.0.4, scala 2.9.2, Java 1.6.37 (osx 1.7), time to circa 0% cpu ~10 seconds.
using akka 2.1.0-rc2, scala 2.10.0-rc2, same jvm, ~60 seconds to 0% cpu.
Testing methodology was horrible, but good enough to see a pretty massive difference in timings.
Testing on another machine seemed to imply this was being caused by huge quantities of time dealing with hash collisions inside HashSet1.
Using akka 2.0.4, scala 2.9.2, Java 1.6.37 (osx 1.7), time to circa 0% cpu ~10 seconds.
using akka 2.1.0-rc2, scala 2.10.0-rc2, same jvm, ~60 seconds to 0% cpu.
Testing methodology was horrible, but good enough to see a pretty massive difference in timings.
Testing on another machine seemed to imply this was being caused by huge quantities of time dealing with hash collisions inside HashSet1.
Leave a comment
file:d_TqxYnCOr4P36acwqEsg8
sbt file
sbt file
on 2012-11-24 06:54 *
By bjorn.antonsson@typesafe.com
A quick run on my machine looked like the active time was spent in SubclassifiedIndex.mergeChangesByKey.
on 2012-11-26 07:43 *
By bjorn.antonsson@typesafe.com
Assigned to set to bjorn.antonsson@typesafe.com
on 2012-11-26 07:46 *
By bjorn.antonsson@typesafe.com
Regression confirmed:
5000 actors subscribing:
2.0.4 ~ 200 ms
2.1.0-RC2 ~ 10500 ms
5000 actors subscribing:
2.0.4 ~ 200 ms
2.1.0-RC2 ~ 10500 ms
So a we returned more than the diff from addValue in SubclassifiedIndex, which lead to an large amount of existing values being processed and then inserted into a HashMap.
The time for 5000 actors subscribing with the fix is ~300 ms, which I think is acceptable since the index now handles classes with multiple traits, which it doesn't do in 2.0.x.
The time for 5000 actors subscribing with the fix is ~300 ms, which I think is acceptable since the index now handles classes with multiple traits, which it doesn't do in 2.0.x.
In master as well