Бенчмарки и профилирование — бесплатный тест онлайн

Вопрос 1 из 30

В разделе «Бенчмарки» показан конкретный случай. Как завершится показанный фрагмент при указанных входных данных?

// Фрагмент для трассировки.
package sample
import "testing"
var sink int
func BenchmarkSum(b *testing.B){for i:=0;i<b.N;i++{sink=i+i}}

Предварительный `Grow` позволяет буферу избежать нескольких перераспределений при известном примерном размере. После ускорения CPU функция исчезает из профиля, но p99 не меняется, если запрос ждёт базу. `go test -race ./...` инструментирует программу и сообщает конфликтующие стеки доступа. Инструмент автоматически подбирает число вызовов функции, пока измерение не станет достаточно устойчивым. Горячая функция занимает большую долю выборок CPU, но это не означает, что её удаление линейно ускорит весь запрос.

Вопрос 2 из 30

Команда проверяет решение по теме «Бенчмарки». Что здесь следует изменить прежде всего?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
import "testing"
var sink int
func BenchmarkSum(b *testing.B){for i:=0;i<b.N;i++{sink=i+i}}

Не помещать инициализацию и проверку результата внутрь измеряемого участка без намерения измерять именно их. Всегда присваивать результат `append` обратно нужной переменной и не полагаться на сохранение адреса элементов. Связывать профиль с трассировками, метриками задержки, блокировок и вводом-выводом. Сначала уменьшать крупные и частые аллокации в горячем пути, подтверждая изменение профилем. Снимать профиль под репрезентативной нагрузкой и сравнивать до/после одинаковым сценарием.

Вопрос 3 из 30

Перед публикацией кода по теме «Бенчмарки» нужно уточнить контракт. Какое правило отделяет верный разбор от правдоподобной догадки?

// Определите правило Go, которое объясняет результат.
package sample
import "testing"
var sink int
func BenchmarkSum(b *testing.B){for i:=0;i<b.N;i++{sink=i+i}}

`-benchmem` показывает байты и число аллокаций на операцию; escape analysis и преобразования интерфейсов могут влиять на результат. Ссылка на полностью подготовленный объект должна передаваться через синхронизирующее событие; простая запись глобального указателя недостаточна. Оптимизировать следует узкое место конечной метрики; высокий процент внутри дешёвой операции может быть следствием отсутствия других затрат. CPU-профиль показывает, где процесс тратил время выборок, а профиль памяти может показывать выделения или живую память. Бенчмарк повторяет операцию `b.N` раз; подготовку можно исключить из времени через `StopTimer` или выполнить до цикла.

Вопрос 4 из 30

В рабочем примере по теме «Бенчмарки» важно отделить гарантию от догадки. Какой крайний случай обязан попасть в тесты?

Профиль короткого запуска может быть шумным, а отладочная сборка — нерепрезентативной. Слишком короткая операция может быть удалена оптимизатором, если результат нигде не наблюдается. В цикле отложенные вызовы выполнятся только при выходе из окружающей функции, что может слишком долго удерживать ресурсы. Flat и cumulative значения отвечают на разные вопросы: собственное время и время вместе с вызванными функциями. Пул объектов может удерживать память, усложнить владение и не гарантирует сохранение каждого объекта между GC.

Вопрос 5 из 30

Фрагмент относится к теме «Бенчмарки». Какой выбор лучше отражает баланс простоты и контроля?

`switch` хорошо показывает взаимоисключающие случаи, но чрезмерный `fallthrough` делает поток управления труднее проверки. Профилирование даёт факты о горячих путях, но само добавляет стоимость и требует осторожного доступа к служебным конечным точкам. Локальная оптимизация может улучшить среднее, но ухудшить хвост из-за блокировок или дополнительной памяти. Микробенчмарк хорошо сравнивает реализацию, но не предсказывает задержку системы с сетью, кешами и конкуренцией. Меньше аллокаций снижает давление на GC, но переиспользование буферов повышает риск утечки данных и гонок.

Вопрос 6 из 30

Команда проверяет решение по теме «Профили pprof». Как изменится состояние программы после этого фрагмента?

go test -bench=BenchmarkSum -cpuprofile=cpu.out ./...
go tool pprof cpu.out

Горячая функция занимает большую долю выборок CPU, но это не означает, что её удаление линейно ускорит весь запрос. После ускорения CPU функция исчезает из профиля, но p99 не меняется, если запрос ждёт базу. Предварительный `Grow` позволяет буферу избежать нескольких перераспределений при известном примерном размере. Функция принимает только `Get`, поэтому и рабочий клиент, и маленькая заглушка удовлетворяют контракту. Инструмент автоматически подбирает число вызовов функции, пока измерение не станет достаточно устойчивым.

Вопрос 7 из 30

Перед публикацией кода по теме «Профили pprof» нужно уточнить контракт. Какое замечание на ревью будет наиболее точным?

go test -bench=BenchmarkSum -cpuprofile=cpu.out ./...
go tool pprof cpu.out
# Задача: выбрать безопасную правку или способ проверки.

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

Вопрос 8 из 30

В рабочем примере по теме «Профили pprof» важно отделить гарантию от догадки. Какое правило важнее случайных деталей конкретного запуска?

go test -bench=BenchmarkSum -cpuprofile=cpu.out ./...
go tool pprof cpu.out
# Требуется объяснить правило, а не только назвать команду.

Бенчмарк повторяет операцию `b.N` раз; подготовку можно исключить из времени через `StopTimer` или выполнить до цикла. CPU-профиль показывает, где процесс тратил время выборок, а профиль памяти может показывать выделения или живую память. Детектор гонок инструментирует доступы к памяти и сообщает конфликтующие стеки, если гонка проявилась во время запуска. Оптимизировать следует узкое место конечной метрики; высокий процент внутри дешёвой операции может быть следствием отсутствия других затрат. `-benchmem` показывает байты и число аллокаций на операцию; escape analysis и преобразования интерфейсов могут влиять на результат.

Вопрос 9 из 30

Фрагмент относится к теме «Профили pprof». Где корректный фрагмент легко становится ошибочным?

Слишком короткая операция может быть удалена оптимизатором, если результат нигде не наблюдается. Пул объектов может удерживать память, усложнить владение и не гарантирует сохранение каждого объекта между GC. Профиль короткого запуска может быть шумным, а отладочная сборка — нерепрезентативной. Аргументы вызова горутины вычисляются до запуска самой функции. Flat и cumulative значения отвечают на разные вопросы: собственное время и время вместе с вызванными функциями.

Вопрос 10 из 30

На ревью разбирают тему «Профили pprof». Что учитывать при выборе этого приёма для публичного API?

Меньше аллокаций снижает давление на GC, но переиспользование буферов повышает риск утечки данных и гонок. Микробенчмарк хорошо сравнивает реализацию, но не предсказывает задержку системы с сетью, кешами и конкуренцией. Совместное владение экономит копирование, но требует ясного контракта мутации и времени жизни данных. Локальная оптимизация может улучшить среднее, но ухудшить хвост из-за блокировок или дополнительной памяти. Профилирование даёт факты о горячих путях, но само добавляет стоимость и требует осторожного доступа к служебным конечным точкам.

Вопрос 11 из 30

Перед публикацией кода по теме «Аллокации» нужно уточнить контракт. Какой результат даст этот код на поддерживаемой реализации Go?

// Фрагмент для трассировки.
package main
import "strings"
func build(parts []string)string{var b strings.Builder;b.Grow(128);for _,p:=range parts{b.WriteString(p)};return b.String()}
func main(){}

Два последовательных объекта могут быть декодированы двумя вызовами `Decode` без предварительного чтения всего входа. Инструмент автоматически подбирает число вызовов функции, пока измерение не станет достаточно устойчивым. Предварительный `Grow` позволяет буферу избежать нескольких перераспределений при известном примерном размере. После ускорения CPU функция исчезает из профиля, но p99 не меняется, если запрос ждёт базу. Горячая функция занимает большую долю выборок CPU, но это не означает, что её удаление линейно ускорит весь запрос.

Вопрос 12 из 30

В рабочем примере по теме «Аллокации» важно отделить гарантию от догадки. Что нужно поменять, чтобы граничный случай не превратился в сбой?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "strings"
func build(parts []string)string{var b strings.Builder;b.Grow(128);for _,p:=range parts{b.WriteString(p)};return b.String()}
func main(){}

Сначала уменьшать крупные и частые аллокации в горячем пути, подтверждая изменение профилем. Использовать явный `return value`, если изменение результата через `defer` не является намеренной и хорошо объяснённой частью контракта. Снимать профиль под репрезентативной нагрузкой и сравнивать до/после одинаковым сценарием. Не помещать инициализацию и проверку результата внутрь измеряемого участка без намерения измерять именно их. Связывать профиль с трассировками, метриками задержки, блокировок и вводом-выводом.

Вопрос 13 из 30

Фрагмент относится к теме «Аллокации». Какое свойство конструкции определяет её поведение?

// Определите правило Go, которое объясняет результат.
package main
import "strings"
func build(parts []string)string{var b strings.Builder;b.Grow(128);for _,p:=range parts{b.WriteString(p)};return b.String()}
func main(){}

Сериализацию проверяют золотыми примерами, круговым преобразованием и испорченным входом; файловые операции — временным каталогом теста. `-benchmem` показывает байты и число аллокаций на операцию; escape analysis и преобразования интерфейсов могут влиять на результат. Бенчмарк повторяет операцию `b.N` раз; подготовку можно исключить из времени через `StopTimer` или выполнить до цикла. Оптимизировать следует узкое место конечной метрики; высокий процент внутри дешёвой операции может быть следствием отсутствия других затрат. CPU-профиль показывает, где процесс тратил время выборок, а профиль памяти может показывать выделения или живую память.

Вопрос 14 из 30

На ревью разбирают тему «Аллокации». Что стоит проверить до переноса решения в общий компонент?

Слишком короткая операция может быть удалена оптимизатором, если результат нигде не наблюдается. Профиль короткого запуска может быть шумным, а отладочная сборка — нерепрезентативной. `time.After` в часто повторяемом цикле создаёт новые таймеры и может удерживать ресурсы до их срабатывания. Пул объектов может удерживать память, усложнить владение и не гарантирует сохранение каждого объекта между GC. Flat и cumulative значения отвечают на разные вопросы: собственное время и время вместе с вызванными функциями.

Вопрос 15 из 30

В разделе «Аллокации» показан конкретный случай. Как точнее всего описать пользу и цену этого решения?

Профилирование даёт факты о горячих путях, но само добавляет стоимость и требует осторожного доступа к служебным конечным точкам. Наблюдаемость очереди помогает увидеть давление, но вмешательство в протокол ради метрики способно создать новые гонки. Меньше аллокаций снижает давление на GC, но переиспользование буферов повышает риск утечки данных и гонок. Микробенчмарк хорошо сравнивает реализацию, но не предсказывает задержку системы с сетью, кешами и конкуренцией. Локальная оптимизация может улучшить среднее, но ухудшить хвост из-за блокировок или дополнительной памяти.

Вопрос 16 из 30

В рабочем примере по теме «Интерпретация профиля» важно отделить гарантию от догадки. К какому результату приводит показанная конструкция?

(pprof) top
flat  flat%   sum%   cum   cum%
1.20s 40.0% 40.0% 1.20s 40.0% parse
0.10s  3.3% 43.3% 2.00s 66.7% handle

Предварительный `Grow` позволяет буферу избежать нескольких перераспределений при известном примерном размере. После ускорения CPU функция исчезает из профиля, но p99 не меняется, если запрос ждёт базу. Запрос к базе с `r.Context()` может прекратиться, если клиент перестал ждать ответ. Горячая функция занимает большую долю выборок CPU, но это не означает, что её удаление линейно ускорит весь запрос. Инструмент автоматически подбирает число вызовов функции, пока измерение не станет достаточно устойчивым.

Вопрос 17 из 30

Фрагмент относится к теме «Интерпретация профиля». Какую правку стоит предложить на ревью, сохранив назначение кода?

(pprof) top
flat  flat%   sum%   cum   cum%
1.20s 40.0% 40.0% 1.20s 40.0% parse
0.10s  3.3% 43.3% 2.00s 66.7% handle

Контекст проверки: Интерпретация профиля.

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

Вопрос 18 из 30

На ревью разбирают тему «Интерпретация профиля». На какой контракт языка или стандартной библиотеки здесь нужно опереться?

(pprof) top
flat  flat%   sum%   cum   cum%
1.20s 40.0% 40.0% 1.20s 40.0% parse
0.10s  3.3% 43.3% 2.00s 66.7% handle

Вопрос относится к теме: Интерпретация профиля.

Бенчмарк повторяет операцию `b.N` раз; подготовку можно исключить из времени через `StopTimer` или выполнить до цикла. Оптимизировать следует узкое место конечной метрики; высокий процент внутри дешёвой операции может быть следствием отсутствия других затрат. `-benchmem` показывает байты и число аллокаций на операцию; escape analysis и преобразования интерфейсов могут влиять на результат. CPU-профиль показывает, где процесс тратил время выборок, а профиль памяти может показывать выделения или живую память. Синхронизацию проверяют под `-race`, повторными прогонами и инвариантами результата, а не только отсутствием паники.

Вопрос 19 из 30

В разделе «Интерпретация профиля» показан конкретный случай. Какое ограничение опаснее всего пропустить?

Профиль короткого запуска может быть шумным, а отладочная сборка — нерепрезентативной. Flat и cumulative значения отвечают на разные вопросы: собственное время и время вместе с вызванными функциями. Методы не могут вводить собственные дополнительные параметры типов сверх параметров типа получателя. Слишком короткая операция может быть удалена оптимизатором, если результат нигде не наблюдается. Пул объектов может удерживать память, усложнить владение и не гарантирует сохранение каждого объекта между GC.

Вопрос 20 из 30

Команда проверяет решение по теме «Интерпретация профиля». Какой вывод о сопровождении решения наиболее взвешенный?

Профилирование даёт факты о горячих путях, но само добавляет стоимость и требует осторожного доступа к служебным конечным точкам. Атомик уменьшает блокировки для простой величины, но алгоритм становится труднее доказать и сопровождать. Меньше аллокаций снижает давление на GC, но переиспользование буферов повышает риск утечки данных и гонок. Микробенчмарк хорошо сравнивает реализацию, но не предсказывает задержку системы с сетью, кешами и конкуренцией. Локальная оптимизация может улучшить среднее, но ухудшить хвост из-за блокировок или дополнительной памяти.

Вопрос 21 из 30

Фрагмент относится к теме «Тестирование и наблюдаемость». Как завершится показанный фрагмент при указанных входных данных?

go test -run=^$ -bench=. -count=10 > old.txt
go test -run=^$ -bench=. -count=10 > new.txt
benchstat old.txt new.txt

`t.TempDir()` создаёт изолированный каталог и автоматически удаляет его после теста. Счётчик заглушки доказывает, что при 401 внутренний обработчик не был вызван. `benchstat` сравнивает несколько выборок и показывает статистическую устойчивость различий. Специальный `Reader` с одним байтом за вызов проверяет, что функция не рассчитывает на заполнение буфера сразу. Тест использует канал результата и таймаут, поэтому различает успешное завершение и зависание.

Вопрос 22 из 30

На ревью разбирают тему «Тестирование и наблюдаемость». Что здесь следует изменить прежде всего?

go test -run=^$ -bench=. -count=10 > old.txt
go test -run=^$ -bench=. -count=10 > new.txt
benchstat old.txt new.txt
# Задача: выбрать безопасную правку или способ проверки.

Запускать тесты многократно, с `-race`, и собирать профили горутин при подозрении на утечку. Запускать `-shuffle`, `-count`, `-race`, хранить медленные интеграционные тесты отдельно и анализировать пропуски покрытия по риску. Запускать серии на стабильной машине, фиксировать входы и отдельно следить за p50/p95/p99, CPU, GC и очередями. Запускать `-race` в CI и на интеграционных сценариях, увеличивать охват конкурентных ветвей и сохранять отчёты. Использовать короткий контролируемый таймаут, синхронизацию запуска и отдельную проверку причины завершения.

Вопрос 23 из 30

В разделе «Тестирование и наблюдаемость» показан конкретный случай. Какое правило отделяет верный разбор от правдоподобной догадки?

go test -run=^$ -bench=. -count=10 > old.txt
go test -run=^$ -bench=. -count=10 > new.txt
benchstat old.txt new.txt
# Требуется объяснить правило, а не только назвать команду.

Синхронизацию проверяют под `-race`, повторными прогонами и инвариантами результата, а не только отсутствием паники. Производительность проверяют устойчивым бенчмарком, базовой линией и эксплуатационными метриками, а не одним быстрым запуском. Публичный пакет проверяют как внутренними тестами, так и внешним пакетом `_test`, примерами и тестами совместимости ошибок. Перед выпуском нужны модульные, интеграционные и нагрузочные проверки критических путей, а после — контролируемое наблюдение новых ошибок и задержки. Сериализацию проверяют золотыми примерами, круговым преобразованием и испорченным входом; файловые операции — временным каталогом теста.

Вопрос 24 из 30

Команда проверяет решение по теме «Тестирование и наблюдаемость». Какой крайний случай обязан попасть в тесты?

Тест только с `bytes.Buffer` слишком дружелюбен и может не выявить ошибочную обработку частичного чтения. Зелёный health endpoint внутри процесса не доказывает доступность базы, очереди и внешнего маршрута. Сравнение общего `runtime.NumGoroutine` без допуска нестабильно из-за фоновых горутин среды. Большой запас уменьшает нестабильность, но маскирует медленную работу; слишком малый порог ломается под нагрузкой среды. Разница в несколько процентов может быть шумом частоты процессора, фоновой нагрузки или компоновки памяти.

Вопрос 25 из 30

Перед публикацией кода по теме «Тестирование и наблюдаемость» нужно уточнить контракт. Какой выбор лучше отражает баланс простоты и контроля?

Глубокая readiness точнее отражает способность обслуживать, но слишком дорогая проверка сама может перегрузить зависимости. Изолированный тест локализует дефект, а тест цепочки ловит ошибки порядка и взаимодействия слоёв. Автоматический порог ловит регрессии, но слишком жёсткий предел создаёт нестабильный CI и привыкаемость к тревогам. Синтетические источники дают детерминизм, но интеграционный тест всё равно нужен для реального файла или соединения. Наблюдаемость очереди помогает увидеть давление, но вмешательство в протокол ради метрики способно создать новые гонки.

Вопрос 26 из 30

На ревью разбирают тему «Конкурентность и эксплуатация». Как изменится состояние программы после этого фрагмента?

go test -run=^$ -bench=. -blockprofile=block.out -mutexprofile=mutex.out ./...

Запись в общую карту без мьютекса из двух запросов создаёт гонку и может вызвать аварийное сообщение runtime. Высокое время блокировки указывает, что горутины ждут канал или мьютекс, хотя CPU может быть свободен. Десятки горутин могут ждать свободное соединение, даже если процессор почти не занят. Атомарный счётчик корректно считает входы без общей блокировки большой критической секции. Снимок горутин показывает множество работников, ожидающих один и тот же мьютекс.

Вопрос 27 из 30

В разделе «Конкурентность и эксплуатация» показан конкретный случай. Какое замечание на ревью будет наиболее точным?

go test -run=^$ -bench=. -blockprofile=block.out -mutexprofile=mutex.out ./...
# Задача: выбрать безопасную правку или способ проверки.

Ограничивать кардинальность меток, контролировать очередь лимитера и не удерживать глобальную блокировку во время `next`. Перестать принимать трафик, снять готовность, дать запросам срок завершиться и затем принудительно закрыть остаток. Зафиксировать влияние, сравнить с последним выпуском, проверить зависимости и сформулировать проверяемую гипотезу с безопасным действием. Снимать профиль блокировок под нагрузкой, проверять длины очередей и не включать дорогой сбор постоянно без оценки. Считать запросы, категории ошибок, гистограмму задержки, очередь и ресурсы зависимостей; связывать с трассировкой через exemplar.

Вопрос 28 из 30

Команда проверяет решение по теме «Конкурентность и эксплуатация». Какое правило важнее случайных деталей конкретного запуска?

go test -run=^$ -bench=. -blockprofile=block.out -mutexprofile=mutex.out ./...
# Требуется объяснить правило, а не только назвать команду.

Расследование строит временную линию из симптома, изменений, метрик, журналов, трассировок и профилей, не начиная с любимой гипотезы. Параллельные запросы разделяют пул, а одна `Tx` обычно привязана к одному соединению и не является удобным общим объектом для независимых горутин. Каждый запрос обычно обрабатывается конкурентно, поэтому общее состояние обработчика должно быть неизменяемым или синхронизированным. Конкурентный дефект может проявляться как редкая порча данных, рост горутин, взаимная блокировка или хвост задержки; нужен набор сигналов. Профили мьютексов и блокировок показывают ожидание, которое не видно в обычном CPU-профиле.

Вопрос 29 из 30

Перед публикацией кода по теме «Конкурентность и эксплуатация» нужно уточнить контракт. Где корректный фрагмент легко становится ошибочным?

Неограниченный запуск горутин может исчерпать сокеты и память раньше, чем сработают таймауты. Неограниченный fan-out к базе превращает краткий всплеск в очередь и каскад таймаутов. Увеличение числа горутин при одном глобальном мьютексе часто лишь увеличивает очередь. Мьютекс, удерживаемый вокруг `next`, последовательно обработает весь сервер и может привести к взаимной блокировке. Бесконечный обработчик или зависшая фоновая горутина могут пережить срок `Shutdown`.

Вопрос 30 из 30

В рабочем примере по теме «Конкурентность и эксплуатация» важно отделить гарантию от догадки. Что учитывать при выборе этого приёма для публичного API?

Разделение блокировки повышает параллелизм, но может разрушить единый инвариант и усложнить код. Длинный льготный срок сохраняет запросы, но замедляет выпуск и может удерживать старую версию слишком долго. Автоматический фон удобен пользователю, но увеличивает скрытые ресурсы и усложняет завершение процесса. Глобальный лимит защищает процесс, но справедливость между маршрутами может потребовать отдельных квот. Параллельность сокращает время CI, но внешняя база или лимит CPU могут стать общим узким местом.