Производительность взаимно блокируемых. Инкремент
1123 Немного опоздал на вечеринку. Но, похоже, никто не упомянул
связывание & amp; минификация из StyleBundle, поэтому ..
@Styles.Render("~/Content/css")
звонит в Application_Start():
BundleConfig.RegisterBundles(BundleTable.Bundles);
, что в свою очередь вызывает
public static void RegisterBundles(BundleCollection bundles)
{
bundles.Add(new StyleBundle("~/Content/css").Include(
"~/Content/bootstrap.css",
"~/Content/Site.css"));
}
RegisterBundles() эффективно объединяет & amp; минимизирует bootstrap.css и amp; Site.css
в один файл,
Но ..
только когда debug установлено на false в Web.config.
В противном случае bootstrap.css & amp; Site.css будет обслуживаться индивидуально.
Не в комплекте и не минимизированы:
5 ответов
Он медленнее, так как заставляет действие происходить атомарно и действует как барьер памяти, устраняя способность процессора изменять порядок доступа к памяти вокруг инструкции.
Вы должны использовать Interlocked.Increment, если вы хотите, чтобы действие было атомарным в состоянии, которое может совместно использоваться между потоками - оно не предназначено для полной замены x ++.
Он медленнее. Однако это наиболее эффективный из известных мне способов достижения потоковой безопасности для скалярных переменных.
Он всегда будет медленнее, потому что он должен выполнить блокировку шины ЦП, а не просто обновить регистр. Однако современные процессоры достигают производительности, близкой к регистровой, поэтому она незначительна даже при обработке в реальном времени.
Подумайте об этом на мгновение, и вы поймете, что вызов Increment не может быть быстрее, чем простое применение оператора приращения. Если бы это было так, то реализация оператора инкремента компилятором вызывала бы Increment внутри, и они выполняли бы то же самое.
Но, как вы можете видеть, проверив это на себе, они не выполнить то же самое.
Эти два варианта имеют разные цели. Обычно используйте оператор инкремента. Используйте Приращение , когда вам нужно, чтобы операция была атомарной, и вы уверены, что все другие пользователи этой переменной также используют взаимосвязанные операции. (Если не все будут сотрудничать, это не поможет.)
По нашему опыту, InterlockedIncrement () и др. В Windows оказывают весьма значительное влияние. В одном примере мы смогли устранить блокировку и использовать вместо нее ++ / -. Одно только это сократило время работы со 140 до 110 секунд. Мой анализ состоит в том, что блокировка вызывает обратное обращение к памяти (иначе как другие ядра могли бы это увидеть?). Чтение / запись кэша L1 составляет около 10 тактовых циклов, а чтение / запись памяти больше, чем 100.
В этом примере я оценил количество операций увеличения / уменьшения примерно в 1 миллиард. Таким образом, на процессоре с частотой 2 ГГц это примерно 5 секунд для ++ / - и 50 секунд для блокировки. Распределите разницу между несколькими потоками, и она приблизится к 30 секундам.