Improve signature management in DDC

[leafpetersen]

We currently use fairly heavyweight helpers to attach signatures to classes - the runtime helpers for this are very hot during startup. We should investigate both optimizing the current paths, and also consider using more declarative mechanisms (e.g. using static properties on the classes instead of attaching them programatically after the fact).

[jmesserly]

do you mean setSignature in particular? yeah that has been on my radar for a while. At some point this thing got really out of control. It distinguishes different kinds of members for no reason, and it does a lot of munging to link up prototypes and deal with lazy eval stuff. This could be simplified a ton.

[leafpetersen]

Yes, setSignature, and then all of the little helpers that it calls (_setConstructureSignature, _setMethodSignature) etc. all show up.

I wrote a lot of this originally, and at the time things were not well thought out with respect to ordering and so I ended up being having to be super defensive to avoid prematurely evaluating types. We can probably do a lot better now.

[jmesserly]

yeah ... we've changed a lot since then!

one thing that's apparent is that our memoized getters aren't performing well. If we want to compute stuff, expanding it inline (like we do for types) is probably better.

Here was my rough idea for signatures:

ClassName[dart.members] = () => (ClassName[dart.members] = constFn({
   // eval base class members
  __proto__: ClassName.__proto__[dart.members]()
  // TODO(jmesserly): do we also need laziness for each member?
  // if so, is there an efficient way to do it?
  bar: dart.method(...), // this is basically just the existing function type.
  foo: dart.getter(...),
  baz: dart.field(...)
}))();

// TODO(jmesserly): figure out how much of this we actually need.
// Static member info should only be needed in rare cases (other than mirrors)
ClassName[dart.staticMembers] = () => (ClassName[dart.staticMembers] = constFn({
  foo: dart.getter(...),
  bar: dart.method(...),
  baz: dart.field(...)
}))();

[jmesserly]

Also we may want to record how often signatures are accessed, and for which types.

For statically typed code, they should not be used. I think the typical uses are:

• method tear-offs (if their RTTI is requested)
• dynamic sends/calls/puts
• mirrors

Let me know if I'm forgetting something. But I think we should optimize for start up. Once someone requests this RTTI, they're already doing something a bit dynamic, so it seems OK to pay for the evaluation cost at that point in time.

[leafpetersen]

Instrumenting to get some ideas of how often this code is used is a great idea, I'll try to make some time to do that later this week.

You're idea for signatures above looks good to me. I had kicked around in my head a similar idea using es6 classes directly, something like:

class ClassName {
  [dart.signature]() { return this[dart._signature] || this[dart._signature] = new ClassNameSig()}
}
class ClassNameSig extends ClassSuperSig {
  // TODO(jmesserly): do we also need laziness for each member?
  // if so, is there an efficient way to do it?
  bar() {return dart.method(...)}, // this is basically just the existing function type.
  foo() { return dart.getter(...)},
  baz() { return dart.field(...)},
  static foo() { return dart.getter(...)},
  static bar() {return dart.method(...)},
  static baz() {return dart.field(...)}
}

There are issues with scoping and with mixins that would need to be worked out though. And given that we've seen es6 stuff be slow, this kind of pattern is probably slower than the pattern that you describe above.

[jmesserly]

I've improved this a bit in https://dart-review.googlesource.com/c/sdk/+/7442

We need to remove mirrors though before we go any further, however. It's difficult to optimize the eventual no-mirrors world while still supporting dart:mirrors.