Помогите разобраться с профайлером
От: hyp1k Россия  
Дата: 07.05.15 14:00
Оценка:
Редко пользуюсь профайлером, помогите разобраться. Есть конструктор некоего класса, запускаю профайлер, смотрю значение Elapsed Inclusive Time для этого конструктора вижу 1,302,050.38 (22 минуты). Думаю: "странно?!". Ограничиваю место вызова конструктора брейкпоинтами засекаю время вручную, отрабатывает за 4 минуты. Других мест вызова конструктора нет. Метод профилирования — Instrumentation. Чего я не понимаю?
c# профайлер производительность profiler
Re: Помогите разобраться с профайлером
От: Sinix  
Дата: 07.05.15 14:11
Оценка: 4 (2)
Здравствуйте, hyp1k, Вы писали:

H>Редко пользуюсь профайлером, помогите разобраться. Есть конструктор некоего класса, запускаю профайлер, смотрю значение Elapsed Inclusive Time для этого конструктора вижу 1,302,050.38 (22 минуты). Думаю: "странно?!". Ограничиваю место вызова конструктора брейкпоинтами засекаю время вручную, отрабатывает за 4 минуты. Других мест вызова конструктора нет. Метод профилирования — Instrumentation. Чего я не понимаю?


1. Instrumentation замедляет выполнение кода, особенно если код в основном занят делом, а не висит в блокировках/вводе-выводе.

2. Не смотрите на точное время, смотрите на соотношение затрат на вызовы внутри конструктора. Он же не сам по себе тормозит

3. Важно правильно мерять время. Если код — числомолотилка, да ещё и с динамическим раскидыванием кода по потокам, то лучше смотреть на sampling + Thread time. Для типового биз-кода с кучей запросов/блокировок etc — wall time. Подробнее — в документации к вашему профайлеру. Для dottrace — тынц.

4. 4 минуты на конструктор — это адов пипец, простите мой французский. Не надо так делать.
Re[2]: Помогите разобраться с профайлером
От: hyp1k Россия  
Дата: 07.05.15 14:51
Оценка:
Sinix, спасибо за ответ.

S>1. Instrumentation замедляет выполнение кода, особенно если код в основном занят делом, а не висит в блокировках/вводе-выводе.

окей, я не знал
S>2. Не смотрите на точное время, смотрите на соотношение затрат на вызовы внутри конструктора. Он же не сам по себе тормозит
Моя проблема в том, что я смотрю и не понимаю, например в конструкторе вызывается самый тормозной метод. В студии пишется вот так:
ManAcc.Service.ReportBuilder.HeadReportDelimiterTree.<>c__DisplayClass37.<CreateDelimitersByAlgoritm>b__2c(class ManAcc.Service.ReportBuilder.HeadReportDelimiter)
Шо за c_DisplayClass, шо за b_2c.

Жму ViewSource, ну вроде бы показывает медленное место, устанавливается курсор на строчку кода. Но соотнести в точности с надписью выше, я не могу этот кусок кода.

Дальше еще веселее, под вот этим куском кода в дереве идет вызов через ORM к свойству, где программа тормозит 90 процентов времени, из-за огромного количества вызовов
ManAcc.Model.Company.ReportBlock.get_ParentBlock_Id()

Как оно может тормозить забирая Id у меня в голове не укладывается?
Вот такой код сгенерирован
[DataMember]
        public Nullable<int> ParentBlock_Id
        {
            get { return _parentBlock_Id; }
            set
            {
                if (_parentBlock_Id != value)
                {
                    ChangeTracker.RecordOriginalValue("ParentBlock_Id", _parentBlock_Id);
                    if (!IsDeserializing)
                    {
                        if (ParentBlock != null && ParentBlock.Id != value)
                        {
                            ParentBlock = null;
                        }
                    }
                    _parentBlock_Id = value;
                    OnPropertyChanged("ParentBlock_Id");
                }
            }
        }
        private Nullable<int> _parentBlock_Id;

S>3. Важно правильно мерять время. Если код — числомолотилка, да ещё и с динамическим раскидыванием кода по потокам, то лучше смотреть на sampling + Thread time. Для типового биз-кода с кучей запросов/блокировок etc — wall time. Подробнее — в документации к вашему профайлеру. Для dottrace — тынц.

Тут тоже засада, мне не везет При sampling у меня на ноуте Win 8 падает critical structure corruption. К сожалению не 8.1 Дома буду пробовать на стационарном компьютере.

S>4. 4 минуты на конструктор — это адов пипец, простите мой французский. Не надо так делать.

Согласен, внесли тут в систему конфигурацию отчета, которая показала слабое программы, поэтому и смотрю, что можно сделать. Говорят нельзя с нуля написать работающий код, его можно только оптимизировать, так что выкинуть и переписать с нуля не выход?!
Re[3]: Помогите разобраться с профайлером
От: Sinix  
Дата: 07.05.15 17:23
Оценка: +2
Здравствуйте, hyp1k, Вы писали:

H>Моя проблема в том, что я смотрю и не понимаю, например в конструкторе вызывается самый тормозной метод. В студии пишется вот так:

H>ManAcc.Service.ReportBuilder.HeadReportDelimiterTree.<>c__DisplayClass37.<CreateDelimitersByAlgoritm>b__2c(class ManAcc.Service.ReportBuilder.HeadReportDelimiter)
H>Шо за c_DisplayClass, шо за b_2c.
Это код, сгенеренный компилятором из лямбды. Dottrace и профайлер студии умеет показывать корректный исходный код, как насчёт остальных — не знаю.
Лямбда живёт в методе CreateDelimitersByAlgoritm, тип ManAcc.Service.ReportBuilder.HeadReportDelimiterTree.

H>Как оно может тормозить забирая Id у меня в голове не укладывается?

Или профайлер ошибается, или реальный код отличается (например, сгенерен прокси-тип и значения подтягиваются по сети), или вызовов там миллиарды. Других вариантов у меня пока нет

H>Тут тоже засада, мне не везет При sampling у меня на ноуте Win 8 падает critical structure corruption. К сожалению не 8.1 Дома буду пробовать на стационарном компьютере.

А, да. Instrumentation тож можно настраивать обычно, что-то типа "Exclude small functions from instrumentation" может помочь.


H>Согласен, внесли тут в систему конфигурацию отчета, которая показала слабое программы, поэтому и смотрю, что можно сделать. Говорят нельзя с нуля написать работающий код, его можно только оптимизировать, так что выкинуть и переписать с нуля не выход?!

Врут. Если использовать профайлер регулярно — то и с производительностью проблем не будет. Но это надо определиться с критериями производительности, написать сценарии для тестов и желательно как-нить автоматизировать сбор и обработку результатов. Короче, недешёвое удовольствие

Тормоза сами по себе — это ещё полбеды. Проблема в том, что у вас тормозит код в конструкторе, обычно это означает, что код или вообще не проверяли на предмет узких мест, или что нашлась ошибка в архитектуре приложения. Обычно долгие операции стараются выносить из конструктора, просто потому что правильно обработать отмену, асинхронность или ошибки в конструкторе — удовольствие ниже среднего.
Re[4]: Помогите разобраться с профайлером
От: hyp1k Россия  
Дата: 08.05.15 08:42
Оценка:
Здравствуйте, Sinix

Профилировщик от jetbrains показал более ожидаемые результаты, а студийный профилировщик (vs2010) оказывается делает BSOD в режиме sampling из-за безопасноти в вин8 .

Ну и с режимом instrumentation от vs не сошлись результаты видимо в вин8 плохо работает профайлер
Отредактировано 08.05.2015 11:45 hyp1k . Предыдущая версия . Еще …
Отредактировано 08.05.2015 9:36 hyp1k . Предыдущая версия .
Отредактировано 08.05.2015 8:43 hyp1k . Предыдущая версия .
Отредактировано 08.05.2015 8:43 hyp1k . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.