1. Куча / Говнокод #25979

    +1

    1. 1
    "Performance is easy. All you need to know is everything" (c) S. Kuksenko (@kuksenk0)

    Умеете профилировать программы?
    Знаете, что такое flame diagram? Умеете посмотреть стектрейс от входа в тред до какого-нить спинлока в ядре? Смотрите асм своего компилятора или джита? Знаете, какая инструкция сколько занимает?
    Умеете по vmstat/iostat или xperf/perf counters увидать проблему и соотнести ее с программой? Используете dtrace голый или с instruments? yourkit? vTune? valgrind? bpf?
    Или такие же дебилы, как я?

    Запостил: MAKAKA, 20 Октября 2019

    Комментарии (59) RSS

    • официальный тред для обсуждения профилировки и перформанса
      Ответить
    • показать все, что скрытоvanished
      Ответить
      • Потому что JIT придет и перехуевертитвсе

        У жабы есть ключ, чтоб репортовать стеки без safepoint, алсо по AsyncGetStackTraces тоже так работает,но есть нюансы
        Ответить
    • показать все, что скрытоvanished
      Ответить
      • А ечсли принтов нет?
        Ответить
      • Да, кстати, речь не о дебаге, а о простофилириловании.
        Ответить
        • показать все, что скрытоvanished
          Ответить
          • показать все, что скрытоvanished
            Ответить
            • В «Visual Studio» профилировщик рисует нормальное дерево вызовов. Я вижу, что 90% времени жрёт вызов foo(), из которых 90% жрёт bar(), в котором 90% занимает вычисление длины вектора — значит, надо оптимизировать работу с векторами в bar().
              Ответить
              • показать все, что скрытоvanished
                Ответить
                • Профилировать релизную сборку. Там, ЕМНИП, надо пару флагов выставить, вроде генерации PDB.
                  Ответить
                  • Он имеет ввиду, что оптимизации могут быть другие наверное.
                    Для жоба и .NET не актуально обычно, а для нативного кода оч даже. Ну тут ты прав: надо профилить релизную сборку, а PDB надо иметь всегда, иначе как ты будешь разбирать краш релизной сборки?
                    Ответить
                    • > иначе как ты будешь разбирать краш релизной сборки?
                      Принтами.

                      Ну да, дебаг-версию профилировать смысла особого нет: там бо́льшую часть ресурсов пожрал долгоносик жрут всяческие assert'ы (в том числе и те, которые внутри CRT), плюс зачастую узкие места дебаг-сборки конпелятор способен оптимизировать сам, и делать это вручную — абсолютно бесполезный труд.
                      Ответить
                      • А какими инструментами ты пользуешься?
                        Используешь ли ты какие-то свои эвенты через EWT (раз уж мы про винду говорим) или только готовые?
                        Ответить
                        • Я пишу говно в «Visual Studio» и теку. Я вообще от «Visual Studio» теку, почти как от «Notepad++». «ETW» не использовал.
                          Ответить
                          • профилируешь-то ты тоже прямо в студии, або берешь что-то типа dotTrace?

                            >«ETW»
                            То-есть весь performance toolkit тож лесом?
                            Ответить
                            • Да, прямо в студии, но редко. Последний раз этим занимался когда пейсал маленькую недопесочницу для личного пользования — там перфоманс критичен был.
                              Ответить
                              • Такую хуйню используеш


                                https://docs.microsoft.com/ru-ru/visualstudio/profiling/media/diag-tools-cpu-usage-tab.png?view=vs-2019

                                ?
                                Ответить
            • Во-первых можно посмотреть сколько раз ты вызываешь это вычисление. возможно, можно сократить это время.

              во-вторых все профилировщики умеют рисовать диаграммы или дерево стектрейсов, и ты можешь увидеть, какая из твоих фунций сильнее всего его дергает.

              например тут
              http://www.brendangregg.com/FlameGraphs/cpu-mysql-filt.png

              видно, что displatch_command БОльшую часть времени делает mysql_parse


              Кроме того, функциясми тебе трудно будет узнать, сколько времени ушло на GC, например
              Ответить
          • Как ты узнаешь, в какое место надо поставить принт?
            Ответить
    • > Или такие же дебилы, как я?
      Да. Ты разве не знал, что программы становятся в два раза медлеенннеее с каждым годом?
      Ответить
    • Удивительно, что никто не упомянул perf под прыщи.

      зы: крышесносный чел научился видеть дджавовый бектрейс вместе с нативным
      https://www.youtube.com/watch?v=D53T1Ejig1Q

      * запилил опцию, чтобы джит не трогал врейм поинтер
      * заставил джита высирать мапы
      * скормил все в perf (линуксоыый обычный профилер главный) и получил объедененный стек
      охуенный
      Ответить

    Добавить комментарий