Go (golang) - современный язык программирования, предназначенный для разработки высококонкурентных приложений, работающих на многопроцессорных системах. Курс даст основы программирования на языке Go, а так же опыт применения языка в основных задачах, которые встречаются сегодня в серверной веб-разработке. В данной части курса будут рассмотрены основы языка и разработки веб-сервисов с использованием стандартной библиотеки. Это курс предназначен для людей с опытом в веб-программировании. Если вы пишете на PHP/Python/Ruby/JS (Node.js) и хотите освоить Go - этот курс для вас. Начинающим программистам может быть немного сложно, т.к. в лекциях используется профессиональных жаргон (сленг), без детальных пояснений. Курс не рассчитан на людей без опыта программирования.
Профилирование через pprof
Loading...
Из курса от партнера Moscow Institute of Physics and Technology
Разработка веб-сервисов на Go - основы языка
276 оценок
Из урока
Работа с динамическими данными и производительность
Дальнейшие работа будет затруднительна без понимания, каким образом в go обращаться с динамическими данными. Поэтому эту лекцию мы начнём с распаковки-запаковки JSON, а далее рассмотрим что лежит под капотом - рефлексию и кодогенерацию, а так же какой из этих подходов быстрее и как это определить.
Познакомьтесь с преподавателями
Романов Василий ВячеславовичTechnical manager
Mail.Ru Group
[БЕЗ СЛОВ] В
предыдущем видео мы рассмотрели каким образом мы можем сравнить два подхода,
каких-то два кода, какой из них быстрее, и мы узнали,
что подход с кодогенерацией будет быстрее, подхода с рефлексией.
Мы пользовались флагом 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, других там нет.
Вы можете использовать либо для бенчмарка.
Более того, вы можете снимать дампы памяти и дампы профилирования процессора
прямо с работающей программы, но это мы будем рассматривать отдельно.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2019 Все права защищены.
