Recientemente leí this post about poor performance of fields marked ThreadStatic - Aparentemente son 60 veces más lentos que el acceso de campo normal. ¿ThreadLocal < de .NET 4 T> funciona mejor?ThreadStatic vs. ThreadLocal <T> Rendimiento: ¿aceleraciones o alternativas?
¿Hay alguna alternativa que ofrezca un almacenamiento específico para hilos de alto rendimiento?
Tenga en cuenta que eso fue en 2008 - I creo que que .NET 4 es mucho más rápido para los campos ThreadStatic que .NET 3.5. No puedo recordarlo con certeza, pero podrías hacer pruebas si quieres.
Dicho esto, la descripción de la prueba no me convence, porque no es realista. ¿Tiene realmente necesidad de leer repetidamente un campo local de subprocesos en un bucle? ¿No es más probable que lo leas una vez y luego, un poco más tarde, en un código diferente?
En última instancia, la verdadera pregunta es si alguno o ambos enfoques funcionan lo suficientemente bien para sus necesidades particulares. Prefiero ThreadLocal<T> a ThreadStatic no por razones de rendimiento, sino porque permite la inicialización adecuada; consulte mi article on randomness para ver un ejemplo.
Dicen que [ThreadStatic] es mucho más eficiente 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 agotan y no se liberan, TheadLocal<T> pasa 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)
Supongo que [ThreadStatic] es el más rápido.
Recuerde siempre comprobar si hay abstracciones con fugas y mire la implementación. Nunca omita prematuramente optimizaciones como esa ;-)
, supongo, he "comparado" ThreadLocal vs ThreadStatic y la sobrecarga es ~ x16. Pero como notó Jon en 99.999999% del caso, esto no es relevante y preferirá ThreadLocal sobre ThreadStatic porque es más fácil de usar. – Pragmateek
Gran artículo al azar, y gracias por la respuesta de Jon. Terminé yendo con ThreadLocal simplemente porque es mucho más inteligente (y seguro para las instancias) en comparación con ThreadStatic. – Mark
@Mark: Exactamente, es mucho mejor :) –