Analyzer memory usage is much higher with a clean cache

[jensjoha]

Via #41793 (comment) I found and checked out https://github.com/kodecocodes/rwf-materials.git and opened the entire directory (after running flutter pub get 500+ times --- I don't know if there's a helper command but that's what I did anyway).

When opening with a clean cache (i.e. rm -rf ~/.dartServer/.analysis-driver/) it ends up using ~14GB of ram. Closing my editor and opening it again it "only" uses ~5GB.

A "hack" is to create and delete a file (which might have to be from the command line) which causes clearLibraryContext() to be called which makes - at least from the used heap perspective - the memory to go down a lot (from ~13.5GB to ~3.5GB) (#51126 about why the heap isn't reduced).

It can't just be called all the time though (e.g. I tried running it after analysis was done (i.e. when transitionToIdle) but that maded for instance go to definition not work because either _priorityResults was now not really valid anymore (that should probably be cleared in clearLibraryContext() too), or the file that was just analyzed was just made invalid because it transition to idle after having analyzed it...

I don't know if there's a "safe" time to run it. Even if there is, it feels like sort of a hack --- it feels like there's a "leak" of sorts via AnalysisDriver._libraryContext -> LibraryContext.elementFactory -> (LinkedElementFactory._libraryReaders and LinkedElementFactory.rootReference) that should be fixed instead.

I'll keep looking, but I'm guessing others have more insight than I do there.

/cc @scheglov

[scheglov]

Yes, it is expected right now that after linking, LibraryElements take more memory than they usually do when loading from the cache. The reason is that after linking, a LibraryElement has all children elements that it could in theory have. But when we read from the cache, we don't build all children of ClassElement(s), and only do this when requested, e.g. when we see a method invocation with this ClassElement as the target. And because not every class of every library is used, we don't build so many elements.

This is a trade-off. If we have all elements ready, we don't need to build them from bytes, but it takes more memory. If we edit a file, and re-build its LibraryElement after each edit, it seems foolish to discard it and read from bytes. But if a library does not get edited again after first analysis, the next time we will not build it, and will read from bytes.

OTOH, in large workspaces, if we don't use some analysis contexts, it could prune them, and discard all their libraries. I'm working on improving heap and CPU usage in the analyzer, and probably will continue doing this for a few following weeks. so, hopefully we could make this better.

[jensjoha]

Below are updated numbers as of 94a541a when opening https://github.com/kodecocodes/rwf-materials.git and waiting until "isAnalyzing":false.

When loading with a clean cache:
current memory: 11.3GB --- peak memory: 11.3GB --- heap 10.5GB of 10.7GB

When loading with a filled cache:
current memory: 3.22GB --- peak memory: 3.22GB --- heap 2.63GB of 2.68GB