Lazy backtrace

[Yamakaky]

Do you think it would be feasible to add some kind of LazyBacktrace? Instead of calling trace then resolve, it would only call trace, then have a fn resolve() -> Backtrace. Alternatively, it could be an enum with Backtrace and Vec<Frame::ip> as variants.

I came on this idea by thinking about rust-lang-deprecated/error-chain#129 (comment).

[alexcrichton]

Seems plausible!

[Yamakaky]

Well, Frame is not clone, so we can't simply get it out of trace(). Do you think it could be Clone?

[alexcrichton]

Seems fine

[Yamakaky]

Yeah, it may be worth to add it. With https://play.rust-lang.org/?gist=6557542b1c00bce1c6528b7daccee877&version=stable&backtrace=1, c() is three times faster that b().

[golddranks]

rust-lang-deprecated/error-chain#129 (comment) If @mitsuhiko is right that CoreSymbolication is especially slow at the rendering phase (and I am understanding correctly that "Lazy" here means that it collects the required info but lazily resolves it when the actual backtrace is needed...), this could lead to tremendous speedups on Mac.

[Yamakaky]

#32

[RalfJung]

I was just hit by this -- Backtrace::new takes multiple seconds the first time it is run, and later it is still extremely expensive. I was wondering why the program suddenly ran so slow, and the reason ended up being Err values that were created and then caught again, but already had their backtrace resolved.

I had to resort to rust-lang/miri#283 to fix this. Unfortunately, this means we have to use the low-level APIs (trace and resolve), which are not particularly pleasant to work with. (Getting an iterator rather than having to specify a closure would make this much nicer ;)

[alexcrichton]

Getting an iterator rather than having to specify a closure would make this much nicer

Agreed! This is unfortunately, however, not possible due to how some platform apis are implemented.