Skip to content

Use escape analysis to catch unnecessary heapification #393

Open
@Manishearth

Description

@Manishearth

Many languages with a pervasive GCs use "escape analysis" to avoid boxing things. So if an object can't escape a given scope, plop it on the stack instead of giving it to the GC heap. This reduces GC load.

While we're not a GCd language, the same principle can apply to the regular heap (with less optimization wins because we already got that optimization win by not having a GC in the first place)

The idea is to find places where optimizations like this are possible.

Basically, if:

  • A vec/string/box/heap thing is constructed locally (Via Vec::with_capacity, vec![], into_string(), Box::new, etc. Catching vec![] will be somewhat hard)
  • It's not modified (we can perhaps allow in-place modification)
  • It's not passed to a function expecting that heap thing (method expecting things like &[T] which are passed a deref coerced Vec are okay)
  • There is no way for the heap thing to "escape" its scope, i.e. by being returned or otherwise moved out.

Then we should suggest using the unboxed version.

This would be a fun lint to work on, but it's not easy. I might work on this myself but I don't have any time right now. Willing to mentor anyone who does want to.

Metadata

Metadata

Assignees

Labels

A-lintArea: New lintsC-an-interesting-projectCategory: Interesting projects, that usually are more involved design/code wise.E-hardCall for participation: This a hard problem and requires more experience or effort to work onT-middleType: Probably requires verifiying types

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions