[Haskell-cafe] STM unperformance

[Wojtek Narczyński]

On 18.02.2016 16:00, Jonas Scholl wrote:
> While your code does not contain any conflicts, the stm-stats library 
> seems to contain some. Replacing trackNamedSTM with atomically speeds 
> things up quite a bit, so most of the time is lost in the library. A 
> short look at the code of the library shows that it uses 
> atomicModifyIORef on some global IORef holding a map of the statistics.

Yes, the instrumentation was the culprit. Thank you!

I'm trying to come up with a (Ord a, Hashable a) => STM (Set a), 
internally partitioned for reduced contention. Looks like my code for 
the Set itself was right, but my code for testing it was ...four 
transactions, inserting one milion elements each. This coudn't have 
worked well, I don't know why it worked at all. Now that I switched to 
four million transactions, inserting one element each, things work much 
better. Perhaps not great, as the 1 OS thread case is still the fastest, 
but 4 OS threads are much faster on the partitioned set then on its 
unpartitioned counterpart.

Overall, inserting transactionally four milion Ints into a Set in one 
second ain't bad at all. Counting them afterwards takes much longer...

-- 
Wojtek