Почему Result<T, E> в Rust такой быстрый?

В Rust гораздо более интеллектуально и оптимизировано распределение дискриминантов перечислений, чем в C с теговыми объединениями, потому что нет способа получить к ним прямой доступ. Кроме того, в Rust есть дженерики в качестве встроенной функциональности, а это означает, что макет Result<T, E> отдельно определяется и оптимизируется для каждой используемой комбинации T и E.

Благодаря дженерикам нет необходимости использовать ссылку: значения содержатся непосредственно в объединении перечисления результатов. Это означает, что минимум в большинстве случаев, когда ошибка представляет собой код ошибки, равен Error + Flag, который составляет 2 байта. (один для дискриминанта ошибки и один для дискриминанта флага).

Однако вам также необходимо иметь возможность возвращать значение, и это значение является обычным случаем. Это значение часто имеет дополнение и превышает значение ошибки. Если это так, компилятор Rust может использовать дополнение для дискриминатора для результата, в результате чего тегированное перечисление имеет тот же размер, что и его наибольшее значение. Это дает вам эффективное освобождение объектов Result с точки зрения использования памяти.

Кажется, вы знакомы с API-интерфейсами, которые возвращают целые числа для сообщения о статусе завершения: ноль в случае успеха и ненулевое значение в случае неудачи. API, выражающий то же самое в идиоматическом Rust, достигнет такой же или лучшей производительности¹, но при этом будет более типобезопасным.

Первый шаг — использовать Result, чтобы классифицировать ценность как успех или неудачу. Поскольку в случае успеха нам не нужно возвращать ничего дополнительно, мы используем ():

Result<(), i32>

При этом он занимает больше места, чем простой i32, поскольку для передачи успеха необходим хотя бы один бит информации. Хотя, чтобы устранить одно из ваших заблуждений, для значения ошибки не существует косвенного указателя; он хранится в строке. Таким образом, это будет 4 байта для i32 + 1 байт для дискриминанта + 3 байта заполнения для достижения 4-байтового выравнивания = 8 байтов.

Как вы упомянули, можно использовать NonZeroI32:

Result<(), NonZeroI32>

В любом случае это могло бы быть потенциально более понятным (в противном случае получение Err(0) может сбить с толку, если вы привыкли к нулю, выражающему успех) и дает Result один дополнительный бит информации, так что размер теперь составляет всего 4 байта, поскольку компилятор может использовать все- нулевой битовый шаблон, который не используется NonZeroI32 для выражения успеха.

Однако это все еще не совсем идиоматический Rust, поскольку NonZeroI32 не особо усовершенствован. Чаще всего тип ошибки определяется как перечисление случаев ошибок:

enum MySimpleError {
    FailureA,
    FailureB,
    FailureC,
}

Result<(), MySimpleError>

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

^{1. It is not likely that values less than a machine word size actually improve performance - only by potentially reducing memory pressure if it can be stored with other small values.}

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

Result<(), Box<MyComplexError>>

Это будет размер машинного слова, поскольку Box гарантированно не будет нулевым, и, таким образом, в случае успеха можно использовать битовый шаблон со всеми нулями, как это возможно с NonZeroI32.

Вы можете обнаружить, что библиотеки уже могут делать это внутри себя. Например, Error из serde-json выглядит так:

/// This type represents all possible errors that can occur when serializing or
/// deserializing JSON data.
pub struct Error {
    /// This `Box` allows us to keep the size of `Error` as small as possible. A
    /// larger `Error` type was substantially slower due to all the functions
    /// that pass around `Result<T, Error>`.
    err: Box<ErrorImpl>,
}

Result<(), serde_json::Error> // does not use any extra space

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