官术网_书友最值得收藏!

Accessing the box

An extra step doesn't sound like much, but it has considerable consequences. This trade-off for easily sharing ownership across various functions or threads removes the ability to put as much data as possible into the CPU's cache, since the pointer makes any data locality difficult. Heap allocations themselves are expensive operations and reducing those will already provide a major speedup.

Furthermore, the compiler cannot deallocate a boxed value if it's still referenced in some places—a problem that occurs especially if the program is large and complex. Similar to orphaned objects in C# or Java, a saved Rc reference can easily be forgotten, creating a memory leak. Therefore, it's recommended to use heap memory only when required.

One principle piece of advice that requires a boxed value in Rust is to "favor object composition over class inheritance" (Gang of Four 1995:20). In the absence of class inheritance, the choice is obviously to use object composition. Considering that you should also "program to an interface not to an implementation" (ibid), there is often a strong wish to put a reference to a trait inside of a struct instead of directly working with the implementation.

To apply this architecture in Rust, the language requires us to put a trait's implementation into a Box<dyn TheTrait>, making it more difficult to handle, test, and reason about. This trait object requires the compiler to rely on dynamic dispatch, which is considerably slower than the default static dispatch.

Static and dynamic dispatch are the two major ways of calling functions in many programming languages, including Rust. While for static dispatch functions, locations are known at compile time, dynamic dispatch functions are only known at runtime and have to be looked up in a vtable that points to the actual address. Both have their merits, so be intentional with their use.

Other than generics, there is no default solution to this issue. The impl Trait addition of Rust 2018 alleviates this issue for function parameters and return values, but cannot be used for field types.

So far, it looks like the best choice is to use concrete types instead of traits to avoid multiple dereference operations—as long as refactoring on change seems to be doable. If you create a library, generics are a better way to go for performance and flexibility.

主站蜘蛛池模板: 定远县| 九龙坡区| 紫金县| 茂名市| 兰溪市| 高雄市| 利辛县| 涞源县| 茂名市| 泸溪县| 禄劝| 乌兰浩特市| 鄱阳县| 平罗县| 环江| 夏邑县| 新田县| 兰西县| 芦溪县| 南溪县| 金川县| 枝江市| 凌源市| 沂水县| 刚察县| 百色市| 吉水县| 古蔺县| 井冈山市| 新乐市| 霞浦县| 南和县| 文登市| 沂水县| 晋江市| 宣武区| 连南| 股票| 双牌县| 宜州市| 新巴尔虎右旗|