These are chat archives for rust-lang/rust

1st
Feb 2019
Zakarum
@omni-viral
Feb 01 10:56
What is preferred way to store sequence of dyn Traits?
Vec<Box<dyn Trait>> has two indirections and many small allocations. I'm interested only in iterating, no index based access.
Sam A. Horvath-Hunt
@SamHH
Feb 01 13:48
This is probably simple... how can I get this to work given that each result has different errors (looked into boxing, a bit confused how I could apply to this)?:
let thing = env::var("THING")
        .and_then(|s| s.parse::<u16>())
        .unwrap_or(5000u16);
essentially take a string result, if it exists then try and convert to a u16 result, then unwrap at the end of fallback to a safe u16
Tim Robinson
@1tgr
Feb 01 13:49
There is .map_err, but I would take advantage of the ? operator's ability to use Into::into:
Ah, you're not interested in the error, because if either env::var or s.parse fails, you want to default to 5000?
Sam A. Horvath-Hunt
@SamHH
Feb 01 13:51
yep
Ingvar Stepanyan
@RReverser
Feb 01 13:52
@omni-viral there are few crates for that (had the same problem recently) but TBH I'd just go with allocations as the overhead turns out not to be that big while it's much safer
alternatively, if you can, use an enum instead of dyn
Tim Robinson
@1tgr
Feb 01 13:52
let thing = env::var("THING").ok()
    .and_then(|s| s.parse::<u16>().ok())
    .unwrap_or(5000u16);
Replace Result with Option using Result::ok
Zakarum
@omni-viral
Feb 01 13:53
@RReverser Hard to use enum in functoin like push<T: Trait>(&mut self, value: T) ))
Ingvar Stepanyan
@RReverser
Feb 01 13:54
yeah if it's generic context, you have a problem :)
Sam A. Horvath-Hunt
@SamHH
Feb 01 13:54
perfect! many thanks @1tgr
Zakarum
@omni-viral
Feb 01 13:54
Basically I have heterogenous structure where user should add his implementations and put them into structure
Denis Lisov
@tanriol
Feb 01 13:57
@omni-viral You may want to look at smallbox if the values tend to be small.
Zakarum
@omni-viral
Feb 01 13:57
They are of any size
Ingvar Stepanyan
@RReverser
Feb 01 13:57
Yes, but this and stack_dst crates will choose the backing storage based on the actual runtime size
So it's kinda helpful
But pretty unsafe and still falls back to Box on large structures
ok finally found that gist where we were playing with the same idea on Twitter https://twitter.com/RReverser/status/1054785798846009344
Denis Lisov
@tanriol
Feb 01 13:59
For large structures the allocation overhead is probably less important...
Ingvar Stepanyan
@RReverser
Feb 01 13:59
So this actually keeps adding differently sized items to the backing storage like Vec does
Zakarum
@omni-viral
Feb 01 14:00
I don't really care of allocations as structure is meant to be built rarely
But it will be traversed regularly
Ingvar Stepanyan
@RReverser
Feb 01 14:00
Then better to just use Vec<Box<...>> still
Zakarum
@omni-viral
Feb 01 14:01
By regularly I mean many times per second. It is kinda performance critical part
Ingvar Stepanyan
@RReverser
Feb 01 14:01
I understand
Zakarum
@omni-viral
Feb 01 14:01
So it would be great if they will fill cache together rather than be scattered
Ingvar Stepanyan
@RReverser
Feb 01 14:01
I understand you're trying to avoid indirection, but it's pretty cheap, and you should also take into account the cost of iteration over same-sized or differently-sized items (which is another indirection).

So it would be great if they will fill cache together rather than be scattered

You're trying to beat the allocator here in managing to allocate items efficiently; really, better don't until it becomes a problem.

Zakarum
@omni-viral
Feb 01 14:03
Yeah. Probably I shouldn't bother until I found it really hits performance
Maybe I will just use SmallVec<[Box<dyn Trait>; ? ]> which seems safer than trying to store unsied values contiguously