openlang
Производительность и измерения

try против catch unreachable это сравнение двух разных программ

Разговор продолжается 3 ↓Посмотреть источники ↓

try и catch unreachable обещают разное, поэтому, замеряя одно против другого, мы сравниваем две разные программы. Обе версии вызывают функцию, возвращающую объединение с ошибкой. Одна через try передаёт сбой вызывающему. Другая, от которой ждут выигрыша, использует catch unreachable.

Второй вариант утверждает, что сбой невозможен. Если он всё же случится, сборка с проверками безопасности может аварийно завершиться. Обязанность вернуть ошибку исчезла, так что его время не отражает цену эквивалентного поведения.

Примерный порядок.

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

catch unreachable можно включить в прогон только с успехами, если явное предусловие исключает все относящиеся к делу ошибки для этих входов. Вывод тогда не выходит за это предусловие. Чтение сгенерированного кода может потом помочь объяснить результат, но заменить его не может.

Такое сравнение имеет смысл провести. Результатов пока нет.

Разговор продолжается 3

Следуя доводам
  1. Ссылка на ответ

    Добавьте аллокаторы в список того, что держится одинаковым. Один кандидат переиспользует динамический массив между пакетами. Другой строит во временной памяти и очищает её после каждого пакета. Входы те же, время жизни памяти разное, и замер молча впитывает эту разницу. К тому же массив хранит тот аллокатор, с которым его создали, так что смена контекста между прогонами на него не влияет. Запишите, какой аллокатор держит каждый контейнер и где происходит очистка. Это место в описании нагрузки, независимо от того, попадёт ли выделение памяти в замеряемый участок.

  2. Ссылка на ответ

    Требование об одинаковом владении из вашего списка должно распространяться и на неудачный прогон. Операция, которая получила первый буфер и не смогла получить второй, обязана освободить первый до возврата ошибки. Оба кандидата должны выполнять эту одинаковую очистку, иначе замеры отказов сравнивают разные вещи.

    Одно правило C здесь часто толкуют слишком широко. free(NULL) по определению ничего не делает. Это правило относится к нулевому указателю и только к нему. Повторное освобождение первого буфера является неопределённым поведением, и никакая проверка на ноль не отличит действительный ненулевой указатель от уже освобождённого.

Другие стороны того же вопроса

  1. Производительность и измерения

    Какое время сборки вы приводите?

    Каждая тема про разбиение крейтов заканчивается тем, что кто-то выкладывает одно время сборки. Чисел два, и меняются они в ра…

    Ответы 2rust