Dyn Traits performance

If your execute method in your benchmark setup doesn't perform significant work with side effects, then without dyn Rust can see through all the layers, see that the number of loop iterations doesn't change the result of the program, and remove the loop entirely.

Calling via dyn isn't slow by itself, but it can't be faster than doing nothing at all. Lack of inlining and optimizations through dyn calls is the main cost usually.

3 Likes

Hi Kornel,
Yes I agree
Basically the methode execute updates few fields of the object which is called (price, quantity, ..), since this method takes &mut self as first argument.
So..

I know that is completely a new question, but do you have experience with arenas in Rust.?
Let explain the use case: I can receive or send as faster as possible millions of orders by sec during short bursts (10 sec), the order is a struct like the sample I had putting in the code above. Those orders have life cycle which is basically; created, on market or rejected, executed or partially executed, cancelled. Only rejected, executed and cancelled are final states and need to clean or delete this order. I'm using currently concurrent dictionary such as Dashmap, but may be there are better options in terms of allocation/deallocation performance and realibility? Thanks by advance for your advice.

You can replace dyn Trait with an enum that can hold all possible types you use. You can even implement traits on that enum.

The enum can be stored directly in a struct, by value, without heap allocations.

Hi Kornel
Thanks.
Yes indeed, this was my first implem, but the concern is the flexibilty and the really fastidious repetitive code, which is error prone and not elegant, since in my case I don't know how many types I need, some new business requirements need to implement several new orders types and add it as plugin.
Of course, using dyn, the result as vtbl should be similar lookup, I think, this is interesting, I don't now if the compiler is enough smart to optimise it.
And there are some features like JIT and PGO for llvm enabled for Rust?

Is there some way to have a "dyn enum" - I'm making up the term here.

What it would do is it would be fun dyn and use a vtable to find methods, but it would explicitly be "pointer sized" or something else small, so that it fits on the stack.
If you tried to make a type implementing the trait that required allocating more memory that trait implementation would need to fail, so rust can guarantee that all of the possible values would fit in the allocated space.

I guess it's almost like a trait bound on the memory layout of the type implementing a trait.

I know this is tricky with rust's lack of guarantees about the memory layout of anything, but maybe one day it would be possible? And hopefully not wildly unsafe! :smile:

You’re essentially describing smallbox, except that it falls back to heap allocation if the value doesn’t fit instead of blocking compilation.

2 Likes

Hi
I've found interesting thinks in the Rustc Book and, yes, indeed there are options to activate PGO for llvm in Rust....
I'll try...

Regards

I don't think anyone raised that question since year 2022. So three years are not enough, maybe in thirty three years something would be done…

This all depends a lot on how how your data is created and how it is interdependent.
You may not need to accumulate them at all and can process as you receive. If you receive the data in large batches it may make sense to accumulate per type. This was you can have direct vectors rather than having your data stored indirectly by having a vector of boxes. In either case it is possible to work without enums by using generic functions.
Lastly if speed is the most important factor it will be likely that you get memory throughput bottlenecked. It may make sense to lay out your data by field rather then by type. For that I would look into entity component frameworks. Not all of them are optimized for this particular purpose tho

1 Like