Хороший доклад, дающий толчок к более глубокому самостоятельному изучению всех аспектов управления памятью в Go. Прекрасная докладчица! Одно все время напрягало - выступавшая с докладом девушка как будто дико стеснялась использовать грамотный литературный русский язык, не могла позволить себе говорить без речевых ошибок почти в каждом предложении. Может быть, это такая стилистика теперь, и это воспринимается как что-то официально-умное и вместе с тем неформально-ненапряжное в речи? Много у кого это вижу :)
Единственное, это поле Старт т.е. временная метка запуска GC от начала исполнения программы.) А время работы GC Wall Duration = 721,248nm => 721 микроСекунда) в первом примере по просмотру времени работы общее время работы GC составило 8.5 milis т.к. было частое срабатывание. Каждое срабатывание требовано 225 micros. Вот и накопилось. Т.е. явно показано, что большой буфер GC увеличивает нагрузку на память, но уменьшает процессорное время. В первом случае 20МБ и 8мс, во втором 1000МБ и 721микрос
Нина завела свой канал на ютубе, подписывайтесь: youtube.com/@pakshinanina
Ну вот когда классно, тогда классно! Браво, Нина!! 👏 Получил огромное удовольствие и пользу от просмотра!
РЕАЛЬНО КРУТО. Прям разжевала и положила в рот😅, осталось только глотнуть информацию. Еще раз спасибо.
Прекрасный доклад, отличный формат, спасибо за труд
Очень интересный доклад. Спасибо, Нина!
Нина, спасибо за доклад!
Спасибо за обратную связь)
Большое спасибо за интересный и полезный доклад!
Отличный доклад, спасибо
Спасибо!
Отличный доклад на простом языке!!!
Крутой доклад
Спасибо!
Это жирный плюс в карму. Но ссылку на репку я так и не нашёл.
Извините, забегались. Добавили ссылку в описание.
спасибо!
А как gc в первый раз вызывается? Изначально живая куча же 0 или я не прав?
лучшая
спасибо - мой случай. Очень помогли. частенько контейнер отваливался аутофмемори :)
Спасибо большое. Но "утечка данных" у Яндекса бывает. А тут речь об утечке памяти.
Спасибо за замечание, оговорилась)
у меня только один вопрос: как линтер пропустил комментарии без точки в конце?))
Спасибо за доклад и ссылки.
Кошмар, безобразие. Он просто был не настроен)
боже, какая шутка я аж упал со стула
Хороший доклад, дающий толчок к более глубокому самостоятельному изучению всех аспектов управления памятью в Go. Прекрасная докладчица! Одно все время напрягало - выступавшая с докладом девушка как будто дико стеснялась использовать грамотный литературный русский язык, не могла позволить себе говорить без речевых ошибок почти в каждом предложении. Может быть, это такая стилистика теперь, и это воспринимается как что-то официально-умное и вместе с тем неформально-ненапряжное в речи? Много у кого это вижу :)
Ссылка на презентацию уже недоступна.
Это мы перенесли слайды в хранилище GitHub.
Новая ссылка: github.com/progmsk/progmsk.github.io/files/14963281/go-garbage-collection.pdf
08:25 ошибка
1 280 185 040 ns = 1.2 s
а не 1 миллисекунда
как бы много мусора = много времени на маркировку и удаление
поправьте если не прав
всё верно. Нано - 10^-9 => 1,2s
Единственное, это поле Старт т.е. временная метка запуска GC от начала исполнения программы.)
А время работы GC Wall Duration = 721,248nm => 721 микроСекунда)
в первом примере по просмотру времени работы общее время работы GC составило 8.5 milis т.к. было частое срабатывание. Каждое срабатывание требовано 225 micros. Вот и накопилось.
Т.е. явно показано, что большой буфер GC увеличивает нагрузку на память, но уменьшает процессорное время. В первом случае 20МБ и 8мс, во втором 1000МБ и 721микрос
Маркировка не входит во время работы GC, на сколько мне помнится. Она не вызывает Stop The World.
кроме стека и кучи есть еще кэш процессора
В каком контексте его можно здесь использовать?