Poor performance due to creating data snapshots

[a701440]

On large less files with a lot of @import(s) and mixins the performance is very poor. It appears to be due to the code constantly running function createCurrentDataSnapshot. If I understand the purpose of this code correctly it is there to preserve the values of variables and mixins in a scope. I think there should be a way to go with some kind of "copy on write" implementation since most scopes don't modify things. In my test files I see upwards of 190 levels with only a few levels having any hashmap(s) in them.

[SomMeri]

You understand it right. It allows easy discard of changes made by mixins and to save the state of the scope for mixins, so that they use variables as they were at the time they were defined (even if imported etc).

It should be easy to create the lazy clone. It would need to be created on write and probably also whenever toIndependentWorkingCopyAllParents is created - due to mixins.

[a701440]

I have experimented with the following changes to LocalScope class:

private LocalScopeData localData = new LocalScopeData(); private Stack localDataSnapshots = new Stack(); private boolean localDataCloned; private boolean localDataCloneOnWrite;

public void createCurrentDataSnapshot() { localDataSnapshots.push(localData); this.localDataCloneOnWrite = true; this.localDataCloned = false; } private void cloneLocalData() { if (this.localDataCloneOnWrite && !this.localDataCloned) { localData = localData.clone(); this.localDataCloned = true; } }

public void discardLastDataSnapshot() { localData = localDataSnapshots.pop(); this.localDataCloneOnWrite = false; this.localDataCloned = false; }

Then all methods that modify the LocalScope add "cloneLocalData" call like this:

public void registerMixin(ReusableStructure mixin, IScope mixinsBodyScope) { cloneLocalData(); getLocalMixins().store(new FullMixinDefinition(mixin, mixinsBodyScope)); }

This reduced the number of "clone" calls by a factor of 2 in your unit tests. I think it's somewhat sub-optimal because I had to call clone in more cases then absolutely necessary, but it helps any way.

[SomMeri]

Related to #320

[SomMeri]

The performance pack pull request implements "copy on read" instead of "copy on write" strategy. Is that enough to close this issue or should I leave this open?