How to speed-up expression evaluation?

[LeaVerou]

Currently, expression evaluation is painfully slow, which makes complex Mavo apps with more than a few hundred records untenable.

There are several reasons for this:

• We optimize for the wrong thing. We only compile each expression once, and we need the compiled JS to execute correctly on every instance of the expression across all items that may contain it. The compiled code is written to calculate as much as possible dynamically, via proxies. There are proxies all over the place, and proxies are slow. It would actually be fine to recompile expressions every time the schema changes, and then we could actually compile them taking into account information about the current schema!
• This means we need to keep track of the current schema, update it each time data is rendered, and take additional actions when it changes. We should be careful not to assume that the schema changes every time data is rendered, otherwise mv-value will be very slow.
• Knowing what changed is done via mv-change events that bubble up DOM nodes. DOM should not be involved in this. If a third-party author needs events to write some JS themselves, they could opt into events.
• Overly eager re-evaluation. Because we don't really know for sure what is inside what, we err on the side of re-evaluation whenever we're not sure. Once we have a representation of the schema, we will know exactly what each identifier resolves to. This will also fix the issues and complexity around where rewriting.
• Because we don't know whether a function needs access to the descendants of an object, we always reevaluate expressions that refer to an object no matter what, even though in most cases we don't need to (e.g. count(people) will re-evaluate every time anything inside people changes). Built-in functions can declare whether they need deep or shallow access, and if all functions used in an expression only need shallow access (the common case), then no need to re-evaluate when descendants change.

Fixing these issues will also address a lot of other problems that stem from not having a representation of the current schema, e.g. #742.