Cache parsed SQL in buildDiagram Function

[ahtrotta]

Fixes #1417

When loading a sequence diagram, the buildDiagram function is one of the most expensive function calls. When it uses the hash getter on an instance of Event, the buildStableHash function is called, which ultimately ends up parsing SQL if the event has any. It turns out that parsing SQL is a relatively expensive operation, so this can add up to a lot of computation if there are a lot of events with SQL in the sequence diagram. In this flame graph you can see that peg$parseRule accounts for 41% of buildDiagram:

This PR creates an LRU cache in the buildDiagram method, and then passes it into the getHashWithSqlCache method on the Event class so that we don't repeat the computation needlessly.

This will need to be split up into two PRs so that we can release a version of @appland/models that will get used in @appland/sequence-diagram.

[kgilpin]

Take a look at

appmap-js/packages/scanner/src/appMapIndex.ts

Line 6 in f0ede48

const ASTBySQLString = new LRUCache<string, QueryAST | 'parse-error'>({ max: 1000 });

which also caches the parse tree.

[kgilpin]

Consider a Map instead of Object.

[kgilpin]

It’s problematic to keep a cache of every SQL query in memory because tools that process many AppMaps will end up consuming a lot of memory doing this. That’s why the scanner uses an LRU cache.

Adding a cache to the Event will impact a lot of code in addition to the code we are trying to optimize.

Can we add the cache we need in a way that’s more specific to the use case. Eg in the DiagramComponent, or an LRU cache in buildDiagram.

[kgilpin]

It’s problematic to keep a cache of every SQL query in memory because tools that process many AppMaps will end up consuming a lot of memory doing this. That’s why the scanner uses an LRU cache.

Adding a cache to the Event will impact a lot of code in addition to the code we are trying to optimize.

Can we add the cache we need in a way that’s more specific to the use case. Eg in the DiagramComponent, or an LRU cache in buildDiagram.

[ahtrotta]

It’s problematic to keep a cache of every SQL query in memory because tools that process many AppMaps will end up consuming a lot of memory doing this. That’s why the scanner uses an LRU cache.

Adding a cache to the Event will impact a lot of code in addition to the code we are trying to optimize.

Can we add the cache we need in a way that’s more specific to the use case. Eg in the DiagramComponent, or an LRU cache in buildDiagram.

I just changed how this works, so now I'm creating an LRU cache in buildDiagram here and then passing the cache into the new getHashWithSqlCache method on the Event class that can be used instead of the hash getter. This won't impact any of the other tools.