On 2013.06.16 03:18:18 +0200, Björn Steinbrink wrote:
> 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.

It was indeed a temporary for which the cleanup revocation dropped the
caching. I handle that case now, which removes another ~200KB from
librustc. PR is at https://github.com/mozilla/rust/pull/7186

Björn
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to