Вам нужно сравнить результаты Go benchmark до и после оптимизации, но один запуск выполнен с race detector, а другой без него. Можно ли считать такие числа напрямую сопоставимыми?
Нет. Запуски с race detector и без него используют разные условия выполнения, поэтому их абсолютные показатели времени, памяти и пропускной способности напрямую сопоставлять нельзя. Для честного сравнения обе версии нужно измерять в одном режиме, а race detector запускать отдельно для проверки корректности конкурентного кода.
Обычные unit-тесты могут не обнаружить ошибку конкурентного доступа, если проблемное межпоточное расписание не возникло во время запуска. Race detector решает другую задачу: он инструментирует выполнение программы и отслеживает конфликтующие обращения к памяти, а не измеряет производительность приложения.
Из-за этого режим диагностики неизбежно влияет на поведение измеряемой программы. Benchmark под race detector полезен для поиска гонок в самом тестируемом сценарии, но его числа не являются обычными production-показателями.
Race detector добавляет обработку обращений к памяти и синхронизации. Это может изменить длительность операций, число выделений, нагрузку на планировщик и взаимодействие горутин с памятью.
Следовательно, разница между двумя benchmark может быть вызвана не оптимизацией, а сменой режима сборки и исполнения. Особенно опасно делать вывод, что одна реализация быстрее или экономнее, если одна из них измерялась с дополнительной инструментализацией.
Обе сравниваемые версии нужно запускать с одинаковыми исходными данными, параметрами benchmark, режимом сборки, архитектурой, настройками процессора и наличием либо отсутствием race detector. В идеале измерения выполняют сериями, потому что на результат также влияют планировщик, фоновые процессы, частота CPU и сборка мусора.
Режим с race detector следует использовать как отдельный этап проверки: он должен показать, нет ли конкурентных ошибок в коде и тестовом сценарии. Результаты такого запуска можно сравнивать с другими результатами только при том же режиме и одинаковой нагрузке; переносить их на обычную производительность нельзя.
Важно различать два вывода: «в режиме race detector эта версия выполняется дольше» и «эта версия медленнее в обычном режиме». Первый может быть корректным только внутри одинаково инструментированных запусков, второй требует обычных benchmark без race detector.
Команда оптимизировала конкурентный кэш. Старый вариант измерили без race detector, а новый — с ним, чтобы одновременно проверить безопасность изменений. Новый benchmark оказался медленнее на 40 процентов.
Рассматривались два варианта. Можно было сравнить полученные числа напрямую, но это смешало бы эффект оптимизации с накладными расходами диагностики. Можно было полностью отказаться от проверки гонок во время эксперимента, но тогда конкурентная ошибка могла остаться незамеченной.
Выбрали разделённый процесс: обе версии проверили под race detector на одинаковом наборе сценариев, затем обе измерили без него в нескольких сериях benchmark. В результате race detector подтвердил отсутствие обнаруженных гонок, а чистое измерение показало реальный эффект оптимизации.
Да, относительное сравнение может быть полезным, если режим, нагрузка и окружение одинаковы. Однако race detector способен по-разному влиять на реализации с различной структурой памяти и синхронизации, поэтому такой результат нельзя автоматически считать прогнозом production-производительности. Это диагностическое сравнение, а не замена обычному benchmark.
Нет. Detector анализирует выполненные пути и обнаруживаемые им конфликты памяти, но не доказывает отсутствие логических ошибок, неверной синхронизации или гонок в непокрытых сценариях. Кроме того, корректный benchmark должен отдельно проверять результат операции, иначе измерение может быть искажено оптимизациями компилятора или ошибкой самого теста.
Нужно запускать старую и новую версии в одинаковом обычном режиме, с одинаковыми входными данными и числом повторов, чередуя порядок запусков при необходимости. Затем сравнивают распределение результатов, а не единственные значения; небольшая разница может быть статистическим шумом. Для итогового вывода полезно применять специализированное сравнение benchmark-результатов и дополнительно проверять корректность обеих версий под race detector.