Object field caching (discussion needed) about go-jsonnet HOT 3 CLOSED

This is quadratic, because every reference to $.A evaluates std.range(1, 3000) again.

{
    A: std.range(1, 3000),
    B: std.makeArray(3000, function(x) $.A[x])
}

from go-jsonnet.

@sparkprime
Continuing discussion from: google/jsonnet#451

Requiring cacheing isn't a good idea because you can't control memory use anymore.

I really don't see how it could make the memory situation noticeably worse. In particular how is it different from keeping values captured in closures? Or even more similar: preparing a local just outside of object? It seems very natural to me that when I have an object I keep all the fields and all the stuff they reference.

There is a lot to gain from field caching.

• I suspect some caching will result in massive speedup in existing real world code.
• It will eliminate the need of hoisting expressions out of objects for performance. Refactoring will no longer have such a drastic effect on performance.
• I think it's what people expect by default. It will eliminate a major footgun for newcomers.
• In some cases it might even improve memory usage - you keep the field only once instead of 17 copies of it.
• Helps a little with cyclic asserts: google/jsonnet#451

I ran a little experiment on code provided by @redbaron (aka @rossmohax). Object field caching reduced evaluation (not counting parsing, analysis etc.) time ~6x. It's 40% speedup if you count static stuff which is the new bottleneck.
(The measurements were performed with this fix applied #183)

from go-jsonnet.

Implemented in #280.

from go-jsonnet.