Just chiming in here with some brief extra context on the performance of Result (which I really need to do a writeup about so that I can just link it):
TL;DR performance of Result is usually fine, but can randomly be a huge problem. However there's also improvements for this on the (distant) horizon. Rust and Swift primarily use an error handling strategy based on Result. For the most part performance is fine, but in some situations you can get really bad problems. LLVM is very bad at optimizing around Results, and tends to have copy and branch heavy codegen as a result (which further hinders other optimizations). This was enough of an issue for the binary deserializer webrender uses for IPC (bincode) that we just landed a rewrite to remove the Results (after several attempts by myself to fix the issues in other ways). [0] Meanwhile, the Swift compiler team used their expertese in llvm to add new custom ABIs and calling conventions to handle these performance issues (the right fix, imo). [1] I need to interview them on these details, to figure out if we can use their work for Rust. (Since runtime performance is mostly excellent, it's difficult to motivate working on this and diverting the limited resources of the Rust team away from the bigger issues like compile times and async-await.) Also Meanwhile, the C++ standards committee is apparently[2] investigating introducing new calling conventions for their new light-weight exceptions proposal (which is basically adding Result to C++ properly). [3] If that work goes forward we should be able to take advantage of it for our own C++ code, and possibly also for Rust. Gonna work on that writeup of this issue now. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1550640 [1]: https://lists.llvm.org/pipermail/llvm-dev/2016-March/096250.html [2]: https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-2019/ [3]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf On Tue, Aug 13, 2019 at 1:01 PM Kris Maglione <kmagli...@mozilla.com> wrote: > On Mon, Aug 12, 2019 at 10:14:19PM -0700, Bryce Seager van Dyk wrote: > >>But either way, that's going to result in a copy when the > >>Result is constructed (unless the compiler is really clever). > > > >Is it the data being moved into the Result which is incurring > >the copy here, or the actual Result that's being returned? > > The former. > > >I would have thought that the data is moved into the Result > >avoids a copy, then the Result itself would be moved or RVOed > >(either way avoiding a copy). > > The move into the result only means that we invoke move rather > than copy constructors when initializing the value stored in the > result. That's more efficient for a lot of things, but still > requires copying data from the old struct to the new one. > > The return value Result is guaranteed to be optimized, though, > so you only wind up with a single copy rather than two. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
