CODEWITHSUNDEEP
rustcollections
Sergio Cavaleiro Costa
Sergio Cavaleiro Costa

Reputation: 560

Rust efficient collection of different types

I am aware of options of trait objects and enum to store different types of objects in a collection, but in both cases, there is a penalty on the runtime efficiency (if I understand it well). In the trait's case, there must be a dynamic dispatch (dyn) and in the enum, all possibilities are checked at runtime (just like a switch). Right? There is a loss of efficiency in both cases, so I was wondering if there is any right way of doing it without that loss.

Using the example in Listing 17-9, for instance:

let screen = Screen {
        components: vec![
            Box::new(SelectBox {
                width: 75,
                height: 10,
                options: vec![
                    String::from("Yes"),
                    String::from("Maybe"),
                    String::from("No"),
                ],
            }),
            Box::new(Button {
                width: 50,
                height: 10,
                label: String::from("OK"),
            }),
        ],
    };

In this case, at compile-time, I know that the vector has those instances, so I don't understand the need for that loss.

How is that different from having a vector of strings? They may also have different sizes.

Upvotes: 0

Views: 657

Answers (1)

effect
effect

Reputation: 1465

Rust doesn't have a general built-in mechanism for doing this with Vecs at compile time, simply because in some (most?) scenarios the types of every object in the Vec is not determinable at compile time. However, it's possible in certain scenarios that the optimizer may be able to figure out that the types are known at compile time and devirtualize the function calls, but you'd have to analyze your compiled code to know if the optimizer was able to do it for your particular case.

It is worth noting that the concern about the inefficiency here possibly may be overblown. While both these methods have some overhead, it's likely this will not be the slowest part of your code's execution (unless you have profiled your code and know otherwise).

Upvotes: 3

Related Questions