The analysis seems to make SPT tests extremely slow. It doesn’t matter how many tests are in a file as long as there are multiple spt files (even if only one is open at a time). After every change in an spt file Spoofax is stuck for minutes (read 5 minutes) doing reanalysis. Sometimes it never terminates. Quite regularly the editor gets blocked. Spoofax is sometimes stuck with hundreds of analysis background jobs. See attachment.

Submitted by Vlad Vergu on 3 December 2013 at 16:47

I assume this is triggered by the project-wide auto-discovery and -analysis. SPT files should not be auto-discovered. Their analysis should be part of the test execution, which is done automatically for open files and for all files by a builder.

Probably. But what is weird is that even if only one file with 1 test is changed, then the analysis schedules very many jobs.

I suspect there’s also a problem with cancellation of analysis jobs which are outdated. We normally don’t see this because a normal file is analysed quickly, but an SPT file takes 30 seconds to analyse.

@Gabriël: Is SPT analysis incremental?

Nope. An approach to make it incremental is to cache the errors, warnings and notes, cache hashes (md5sums or something) for each test AST and only re-do the analysis if the hash changes. This would still require a re-parse of the entire file though.

We did some debugging and found out the cause. Each execution of a test in the SPT file causes the entire project to be re-analyzed, because the index and task engine are cleared every time. This only manifests as a problem if you mix spt and language files, because it will re-analyze all language files many times. The workaround for now is to separate spt and language files. I will look into fixing this.

Edit: The actual cause is the analysis of language files failing, causing the index/task engine for that language not being stored, triggering re-analysis every time.