Performance

[whitlockjc]

Fixing issue #82 was a brute force attempt. With all the feature adds and bug fixes, it's time to revisit performance.

[noahdietz]

So how much of a difference did the first pass make at improving performance?

Idk if it'd make much of a difference, but you're using arrays, and searching the entire array each time for a previously visited reference. Unless you limit the depth of the circular relationship, this will become the slowest aspect I think, and predictably so...I'm not entirely sure, but could using a Javascript object as a map, keyed by refPtr, make searching (access runtime) for an already visited refPtr faster?

Also, does limiting the traversal depth help here? or making it configurable maybe? Eventually you have to stop evaluating a circular dependency, I'm just wondering what your stopping point is.

[whitlockjc]

The real problem is processing the same documents and references more than once. I've solved this locally. The other problem is the approach taken to identify circular references and for resolving the references. Instead of finding all references and working out if they are circular or not, I need to process each reference once, identify its dependencies (what other referenceable objects are below the referenced object), resolve references as they are encountered and use simple logic to identify circulars after the fact.

I've got it all figured out, and most of it worked out locally. I just need to finish the work.