On 2013.06.15 20:46:44 +0200, Björn Steinbrink wrote: > On 2013.06.15 11:34:16 -0700, Graydon Hoare wrote: > > On 15/06/2013 10:09 AM, Björn Steinbrink wrote: > > > > >This seems to be due to the landing pads for the function calls. Each > > >contains one more call to drop, so the code grows quadratically with the > > >number of allocations. > > > > Yes. Last time I was in the landing pad code (on the return-unwind > > branch) I was concerned that this was happening. I deferred a fix > > because we were in "get it working" mode. I suggest anyone wanting > > to help attack that first and foremost. > > Seems interesting, I'll give it a shot.
OK, so I have a hackish version [1] that "mostly" handles growing landing pads within a single scope (in nested scopes, the parent cleanup blocks are already reused). "Mostly" because there seems to be some problem with e.g. ~int. Consecutive "let x = ~5" lines don't create chained cleanup blocks, yet. This is probably because of some temporary cleanups, as the shrinking of the cleanup vector isn't adjusted yet as still forces the creation of a completely new landing pad. I'll look into that tomorrow. The results so far are very promising, though. Compile time for librustc drops from ~2:35 to ~2:20, the size of mk_ctxt drops from 127180 to 63738 and librustc itself drops from 15294384 to 14901376. Björn [1] https://github.com/dotdash/rust/commit/e736b567bdfdb44da2436b5b079356d79321b3e6 _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
