7 + 14 == 14

[swizard]

Современные компьютеры, конечно, весьма загадочные звери.

Профилировал тут давеча callgrind-ом один бинарь: смотрю -- наверх всплывают две тяжёлые функции, допустим, A и B. На первую процессор тратит 14 млрд тиков, на вторую 7. Вклад всего остального, допустим, несущественен

Comments

[izard]

Логично, профилировать надо релизный билд с символами в неинструментирующих средах - vtune, linux perf, oprofile. Тогда под профайлером и без результаты отличаться не будут.

[nponeccop]

Они (инструментирующие и неинструментирующие) дополняют друг друга. Профилировать надо и там и там, и только релизные билды с символами (оптимизация + релизная libc). Дебажные билды вообще смысла нет профилировать, даже с оптимизацией, по-крайней мере в случае MSVC, т.к. дебажная MSVCRT довольно непредсказуемо срёт в производительность.

Я вообще отказался в MSVC от дебажной црт - для отладки компилирую с релизной црт, но без оптимизации. А символы всегда включены, даже в релизных билдах. Ещё иногда map делаю, он помогает, если облом затаскивать с продакшена минидампы.

В последний раз, когда я проверял, неинструментирующий vtune давал больше информации по performance counters, но меньше по дереву вызовов, т.е. месту где собственно чинить боттлнек, чем инструментирующий AQTime

[izard]

никогда не пробовал под винду собирать с call graph, но под linux - vtune vtss коллектор вроде нормально собирает давно уже.

[swizard]

На самом деле, профилировать-то ещё ладно, можно хоть printf-ами с таймингами все вызовы отсмотреть.

А делать-то что, когда оказывается, что bottleneck в доступе к RAM, и твой восьмиядерный зеон используется на 1% от своего потенциала? :)

Хоть на магнитофонной ленте отлаживайся...

[ext_732529]

А какого размер код, И как плотно/локально друг к другу он упакован? А то может и такое случиться, что на промахи в кэш уже внимания можно будет не обращать...

[swizard]

код не очень большой (~250kb в скомпилированном виде)

вряд ли его имеет смысл особенно как-то упаковывать