Avoid creating most trees in GenBCode

[odersky]

GenBCode generates trees when it desugars Idents based on their type.
We now cache the generated tree, avoiding generating the same tree several times.

In the Dotty bootstrap, this reduced generated trees in backend from 606K (about 20%
of total) to 49K.

[odersky]

test performance please

[dottybot]

performance test scheduled: 1 job(s) in queue.

[dottybot]

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/3085 to see the changes.

Benchmarks is based on merge(s) with master

[nicolasstucki]

LGTM

[smarter]

There is already code that attempts to cache the output of desugarIdent: https://github.com/dotty-staging/dotty/blob/6e6df180d46774651bea43a443f9d074020f68df/compiler/src/dotty/tools/backend/jvm/DottyBackendInterface.scala#L922-L926 With the cache you added, it should now be redundant. I'm also wondering if the added cache could cause memory leaks in the IDE.

[lrytz]

Curious: is that something that affects scalac too? Where does GenBCode generate trees?

[odersky]

@smarter The thing you are seeing is just a single element cache to support name-based pattern matching. I think it could indeed be eliminated.

I don't think we'll have a problem with space leaks because DottyBackendInterface is re-created for each run.

@lrytz The trees get created because dotc can represent paths with simple Ident nodes (the precise info is in the type of the ident, which is a TermRef). So I don't think this affects scalac.

[odersky]

Unfortunately it looks like our tests are still too noisy to be able to tell with confidence whether a change helps or not. It would be good to also use the scalac infrastructure for comparison.

[odersky]

@smarter It turns out the desugared field in the Select object of DottybackendInterface is not just a cache but core to the way values are deconstructed. Changing it would require major surgery.