ThreadStatic vs. ThreadLocal<T> Performance: speedups or alternatives?

Question

I recently read this post about poor performance of fields marked ThreadStatic - they're apparently 60x slower than normal field access. Does .NET 4's ThreadLocal< T > perform any better?

Are there any alternatives that offer high performance thread-specific storage?

Fish

Answer 1

Bear in mind that that was in 2008 - I believe that .NET 4 is a lot faster for ThreadStatic fields than .NET 3.5 was. I can't remember for sure, but you could run tests if you want.

That said, I'm not really convinced by the test description - because it's unrealistic. Do you really need to repeatedly read a thread-local field in a loop? Isn't it more likely that you'll read it once, and then once a bit later on in a different bit of code?

Ultimately, the real question is whether either or both of these approaches performs well enough for your particular requirement. I prefer ThreadLocal<T> to ThreadStatic not for performance reasons, but because it allows for appropriate initialization - see my article on randomness for an example.

Tirrell

Great article on random, and thanks for the answer Jon. I've ended up going with ThreadLocal simply because it's way smarter (and instance-safe) compared to ThreadStatic. – Fish

A ThreadLocal requires a Dispose() call on every thread which caused its value to be initialized. That's necessary if the resources are to be garbage collected and to avoid memory leaks. Remembering to add this Dispose() call in every thread for all possible ThreadLocals the thread might have used is challenging. Using Dispose() in pooled threads is a nightmare (don't attempt it!) Plus, looking at MS reference source for ThreadLocal, it essentially creates a ThreadStatic table (per thread) of all ThreadLocals used anywhere in your code, that seems inefficient for many ThreadLocals. – Flipflop

Answer 2

They say that [ThreadStatic] is much more performant than Thread.AllocateDataSlot.

The implementation of ThreadLocal<T> (according to Reflector) has 16 dedicated types that just use [ThreadStatic] under the cover. Once they are used up and not freed, TheadLocal<T> switches over to Thread.AllocateDataSlot. (Actually it seems to be 16^3 slots per <T>, they do a very funny scheme of creating generic types to hold the slots)

So I guess [ThreadStatic] is the fastest.

Remember to always check for leaky abstractions and look at the implementation! Never prematurely skip optimizations like that ;-)

Ywis

good guess, I've "benchmarked" ThreadLocal vs ThreadStatic and the overhead is ~x16. But as noticed by Jon in 99.999999% of the case this is not relevant and you'll prefer ThreadLocal over ThreadStatic because it's more user-friendly. – Nuclei