Performance issues from dependency-checking on val computation

[joshuahhh]

Some diagrams which used to work OK now take dozens of seconds to load. Profiling suggests that > 90% of these diagrams' render time is spent in Attribute._value's call to Attribute.circularReferencePath, so I'm guessing this is #32's fault.

Example of a very slow drawing: Field.json.txt.

I'm not sure exactly what property of a drawing makes it susceptible to this slow-down. But the Field drawing has a large spread. It makes sense that not caching the circular-reference check would cause especially big problems for drawings like that.

[electronicwhisper]

Yeah, probably some caching would fix this.

"Nested" spreads in general are a little shakey performance-wise in my experience. By nested spreads I mean for example the 2D grid where both X is a spread and Y is an independent spread, requiring a cross-product of the two spreads. I am not sure if this is a result of the nesting or just a result of so many iterations. It would be interesting to test performance of a spread (0, 100) versus two "nested" spreads (0, 10).