[БЕЗ СЛОВ] В
предыдущем видео мы рассмотрели каким образом мы можем сравнить два подхода,
каких-то два кода, какой из них быстрее, и мы узнали,
что подход с кодогенерацией будет быстрее, подхода с рефлексией.
Мы пользовались флагом benchmem у бенчмарка,
и в этом видео мы поговорим о том,
как посмотреть не просто какой вариант быстрее,
а за счет чего какой-то вариант быстрее или медленнее.
В Go вы можете снять профиль либо процессора,
используя директиву cpuprofile и путь
куда складировать данные,
либо профилирование памяти.
Причем, я указал rate 1,
то есть фактически регистрировать в каждую локацию.
Вы можете использовать либо и CPU, и память вместе, либо по отдельности.
Я использую вместе для того, чтобы он мне их построил.
Сейчас я это запущу.
Итак, я запустил.
Видно, как по-прежнему, что кодогенерация будет быстрее практически в два раза.
Теперь я хочу посмотреть, почему.
Когда я снял профиль, теперь мне нужно его каким-то образом проанализировать.
В Go для этого есть инструмент, называется pprof.
Запускается он таким образом: go tool pprof,
ваш выполняемый файл.
Если вы собираете его через test,
то вот он таким образом собрался: test.exe и путь к профилировщику.
Начнем мы с CPU.
[БЕЗ СЛОВ] Запустился pprof.
Сначала давайте посмотрим на топ операции, которые выполнялись.
Ну, тут только runtime, то есть чисто сам runtime Go.
Тут нет наших операций, они не были достаточно быстрые.
Но я могу ввести нужную мне
функцию и посмотреть, что именно там, где занимало время.
Я знаю мою функцию, она называется Unpack, точнее их там две.
Я использую команду list и ввожу функцию Unpack, и теперь мне
вывелись на экран те места,
где было сколько-либо много
задействовано CPU времени.
Посмотрим сначала UnpackBin, это кодогенерация.
Вот где, что тут тратило время.
В основном, конечно, это чтение бинарных данных затрачивается,
ну, и преобразование слайса byte в строке.
А если мы посмотрим рефлексию,
то мы не только тратим время на чтение бинарных данных,
но еще и на их установку вот здесь, и вот тут тоже.
Но по коду иногда бывает ковыряться не очень много, хочется как-то и с высоты
птичьего полета обозревать свою программу, свои владения и смотреть, что там как.
Для этого pprof может строить уже картинку с
графиком в любом нужном вам формате, либо вы можете запустить ее прямо из pprof.
Делается это: команда web, enter.
У меня открылся браузер, и теперь видны фактически все кишки.
У меня не очень много горячих мест.
На самом деле все горячие места занимают runtime и операции, там, с памятью.
Но, тем не менее, тут можно найти мои программы.
Вот отлично!
Смотрите, вот test, вот BenchmarkCodegen.
Так, 0.17, а вот BenchmarkReflect, 0.25,
и дальше мы уже можем смотреть, где тут что выделяется.
Например, UnpackReflect,
они все выделяли какие-то новые объекты, все читали,
но вот Reflect куда-то ушел, ушел, ушел, ушел...
куда-то ушел в runtime.
Таким образом, вы можете найти нужное
узкое место и попробовать его оптимизировать.
Но это профиль CPU, давайте теперь посмотрим на профиль памяти.
Указываем mem.out.
В профиле памяти несколько разных режимов.
Тут можно посмотреть место, которое в данный момент занимает либо по количеству
объектов, либо по самой памяти либо места, где были совершены больше всего локаций.
Вот например, если я введу сразу, то в данный момент в основном занимает runtime,
и, более того, я больше всего вижу снятие самого хипа тут,
но если я посмотрю на аллокации, alloc...
это команда alloc_space, где были произведены аллокации.
Теперь смотрим top, и уже в top я вижу свои функции: UnpackBin,
UnpackReflect, Codegen, BenchmarkReflect.
Теперь я опять могу использовать команду list и посмотреть Unpack,
где было выделение.
Как всегда Reader с присваиваемой переменной
и выделение слайса byte для чтения.
string — конвертация слайса byte в строку, ну, и так далее.
Это кодогенерация, а вот reflect.
То есть помимо того, что я читаю, вот тут еще много выделено памяти.
Что это такое?
Это присвоение в поле.
То есть я не сразу присваиваю в поле структуры,
а должен провести это через reflect.Value.
Ну и тоже слайс byte.
Точно так же как и CPU, мы можем посмотреть на это в виде web.
Web.
И тут мы уже можем увидеть чуть-чуть побольше.
Смотрите, тут уже все-таки наша программа в этих местах выделила больше памяти.
Посмотрим, UnpackReflect и UnpackBin — они оба используют binary.Read,
оба выделяют строку, но вот Reflect,
в ряд с reflect еще тратит на reflect.(*rtype).Field,
reflect.(*structType).Field, то есть это вот он,
вот как раз overhead, который накладывает Reflect на ваши оперции.
Здесь его наглядно видно.
Так, это было alloc_space,
а теперь давайте посмотрим, где именно сами объекты выделялись.
[БЕЗ СЛОВ] [БЕЗ
СЛОВ] [БЕЗ СЛОВ] Ну,
по-прежнему мы видим, что там же,
хотя на первом месте выделяется создание новой строки.
Также давайте посмотрим по-прежнему нашу функцию Unpack.
Ну и где были объекты?
Вот здесь объекты, вот здесь много было выделено, ну, и также вот тут.
О, всего одна!
Всего один объект выделяется на данном Unpack.
Это очень мощный инструмент исследования.
Вы можете глубоко-глубоко зарыться туда и при помощи него
оптимизировать вашу программу так, как вам надо.
Ну, и давайте под конец посмотрим web.
Ну, и опять web уже AllocObject], где какие объекты были выделены.
Смотрите, вот UnpackBin, то есть метод, который был получен кодогенерацией.
Он всего лишь выделяет строку, ну и считает бинарные данные.
А вот метод, который распаковывает данные через Reflect.
Он не только читает бинарные данные,
но еще и использует конвертацию в пустой интерфейс,
вот этот вот кусок: runtime.convT2E, ну, и структуры Reflect:
reflect.(*rtype).Field и reflect.(*structType).Field.
Вот тут тоже видно overhead, который накладывает Reflect,
и именно из-за чего Reflect медленнее, чем кодогенерация.
pprof — очень мощный инструмент.
Я dам рассказываю только про очень мощные инструменты в Go, других там нет.
Вы можете использовать либо для бенчмарка.
Более того, вы можете снимать дампы памяти и дампы профилирования процессора
прямо с работающей программы, но это мы будем рассматривать отдельно.
