.net - ThreadStatic vs. ThreadLocal<T> Rendimiento: ¿aceleraciones o alternativas?

thread-local

Question

Hace poco leí esta publicación sobre el bajo rendimiento de los campos marcados como ThreadStatic : son aparentemente 60 veces más lentos que el acceso a campos normales. ¿El ThreadLocal <T> de .NET 4 funciona mejor?

¿Hay alguna alternativa que ofrezca almacenamiento de alto rendimiento para subprocesos específicos?

Answer 1

Dicen que [ThreadStatic] es mucho más Thread.AllocateDataSlot que Thread.AllocateDataSlot .

La implementación de ThreadLocal<T> (según Reflector) tiene 16 tipos dedicados que solo usan [ThreadStatic] debajo de la cubierta. Una vez que se usan y no se liberan, TheadLocal<T> cambia a Thread.AllocateDataSlot . (En realidad, parece ser 16 ^ 3 ranuras por <T> , hacen un esquema muy divertido de crear tipos genéricos para mantener las ranuras)

Así que supongo que [ThreadStatic] es el más rápido.

¡Recuerde siempre comprobar si hay abstracciones con fugas y ver la implementación! Nunca omita prematuramente optimizaciones como esa ;-)

Answer 2

Tenga en cuenta que eso fue en 2008: creo que .NET 4 es mucho más rápido para los campos ThreadStatic que para .NET 3.5. No lo recuerdo con seguridad, pero podrías hacer pruebas si lo deseas.

Dicho esto, no estoy realmente convencido por la descripción de la prueba, porque no es realista. ¿ Realmente necesitas leer repetidamente un campo de subproceso local en un bucle? ¿No es más probable que lo lea una vez, y luego una vez un poco más adelante en un bit de código diferente?

En última instancia, la pregunta real es si uno o ambos de estos enfoques funcionan lo suficientemente bien para su requerimiento particular. Prefiero ThreadLocal<T> a ThreadStatic no por razones de rendimiento, sino porque permite una inicialización adecuada; consulte mi artículo sobre aleatoriedad para ver un ejemplo.