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

Вопрос 1 из 30

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

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

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

Вопрос 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}}

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

Вопрос 4 из 30

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

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

Вопрос 5 из 30

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

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

Вопрос 6 из 30

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

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

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

Вопрос 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
# Требуется объяснить правило, а не только назвать команду.

Детектор гонок инструментирует доступы к памяти и сообщает конфликтующие стеки, если гонка проявилась во время запуска. Оптимизировать следует узкое место конечной метрики; высокий процент внутри дешёвой операции может быть следствием отсутствия других затрат. CPU-профиль показывает, где процесс тратил время выборок, а профиль памяти может показывать выделения или живую память. Бенчмарк повторяет операцию `b.N` раз; подготовку можно исключить из времени через `StopTimer` или выполнить до цикла. `-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(){}

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

Вопрос 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(){}

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

Вопрос 14 из 30

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

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

Вопрос 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

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

Вопрос 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` или выполнить до цикла. Синхронизацию проверяют под `-race`, повторными прогонами и инвариантами результата, а не только отсутствием паники. `-benchmem` показывает байты и число аллокаций на операцию; escape analysis и преобразования интерфейсов могут влиять на результат. CPU-профиль показывает, где процесс тратил время выборок, а профиль памяти может показывать выделения или живую память. Оптимизировать следует узкое место конечной метрики; высокий процент внутри дешёвой операции может быть следствием отсутствия других затрат.

Вопрос 19 из 30

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

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

Вопрос 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

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

Вопрос 22 из 30

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

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

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

Вопрос 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

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

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

Вопрос 25 из 30

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

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

Вопрос 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 ./...
# Задача: выбрать безопасную правку или способ проверки.

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

Вопрос 28 из 30

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

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

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

Вопрос 29 из 30

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

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

Вопрос 30 из 30

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

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