If you are writing a performance critical service in @rustlang, and you want to perform tracing. Would you be more concerned about monomorphization (T: TracingFramework), or trait objects (&TracingFramework) for your framework integration?
-
-
Trait objects require heap allocation, for one. From a performance standpoint it's often beneficial to stick with parametric polymorphism whenever possible.
2 replies 0 retweets 1 like -
And sometimes, boxing can be faster; take errors for example. Gotta measure! These cases are fewer but do exist
1 reply 0 retweets 0 likes -
Faster in what way? A Box<Error> is still going to require allocation where the monomorphic version will not, right?
1 reply 0 retweets 0 likes -
Replying to @evan_cam_ @rustlang and
If there *is* an error, it's not faster. But if most of the time you don't have an error, you save a lot of time because the result can be much smaller (since it needs at most a word with which to store the error). Boxing is thus often a good choice for error handling.
1 reply 0 retweets 1 like -
Replying to @awesomeintheory @rustlang and
Of course it won't be allocated unless there's an error, just wondering what the claim that it's "faster" is based on.
1 reply 0 retweets 0 likes -
Replying to @evan_cam_ @rustlang and
At least for me: benchmarking. Copying gigantic Result structs that are usually empty can massively slow down code (plus, you have worse locality of reference on the stack).
1 reply 0 retweets 0 likes -
Replying to @awesomeintheory @rustlang and
Definitely not arguing against boxing errors, I do it in my code also. I was just responding to the original comment about why most code is written without trait objects. Cheers
1 reply 0 retweets 1 like
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
