ThreadStatic против ThreadLocal <T>Производительность: ускорения или альтернативы? - PullRequest
22 голосов
/ 30 сентября 2010

Я недавно прочитал этот пост о плохой производительности полей, помеченных ThreadStatic - они, очевидно, в 60 раз медленнее, чем обычный доступ к полям.Работает ли в .NET 4 ThreadLocal лучше?

Существуют ли альтернативы, которые предлагают высокопроизводительное хранилище, ориентированное на потоки?

Ответы [ 2 ]

30 голосов
/ 30 сентября 2010

Имейте в виду, что это было в 2008 году - я считаю , что .NET 4 намного быстрее для ThreadStatic полей, чем .NET 3.5. Я не могу вспомнить наверняка, но вы можете запускать тесты, если хотите.

Тем не менее, я не совсем уверен в описании теста - потому что это нереально. Вам действительно нужно многократно читать локальное поле потока в цикле? Разве не более вероятно, что вы прочтете это один раз, а потом чуть позже в другом кусочке кода?

В конечном счете, реальный вопрос заключается в том, достаточно ли одного или обоих этих подходов достаточно для ваших конкретных требований. Я предпочитаю от ThreadLocal<T> до ThreadStatic не по соображениям производительности, а потому, что это допускает соответствующую инициализацию - см. Мою статью о случайности для примера.

22 голосов
/ 03 октября 2011

Говорят, что [ThreadStatic] гораздо более производительный, чем Thread.AllocateDataSlot.

Реализация ThreadLocal<T> (согласно Reflector) имеет 16 выделенных типов, которые просто используют [ThreadStatic] под крышкой. Как только они израсходованы и не освобождены, TheadLocal<T> переключается на Thread.AllocateDataSlot. (На самом деле, это кажется 16 ^ 3 слотов на <T>, они делают очень забавную схему создания универсальных типов для хранения слотов)

Так что, я думаю, [ThreadStatic] самый быстрый.

Не забывайте всегда проверять наличие утечек абстракций и смотреть на реализацию! Никогда не пропускайте преждевременно такие оптимизации; -)

...