[analyzer] multiple copies of plugin launched

[ookami-kb]

If you have a monorepo with several packages, and these packages use different versions of some analyzer plugin (dart_code_metrics in our case), or you have both Flutter and pure Dart packages in this monorepo, you end up with multiple plugin instances running – the CPU and memory consumption goes very high in this case and analyzer performance degrades pretty noticeably.

Analysis Server Diagnostics screenshot:

This is understandable since they have different package paths, but probably there's a way to reuse some entities (if it's not already the case) to reduce memory / CPU utilization.

The problem with different plugin versions is solvable (we can and we should unify plugin versions within monorepo anyway), but mixing Dart and Flutter packages is a common case, and having 2 plugin instances running is a pain point.

[bwilkerson]

Yes, we should look into fixing this. Right now we use the 'bootstrap package path' to determine uniqueness. This works for the case where you're running multiple versions of a plugin, but fails to take into account that there are two locations for the .pub-cache directory.

@incendial @jacob314

[srawlins]

flutter/flutter#53833 has a discussion on issues caused by the Flutter-local pub cache (and there are references to 4 other related issues).

[srawlins]

@ookami-kb Thanks for the great details. Can you hazard a guess about how this happened? One guess I have is that flutter packages get was run in one package, and dart pub get was run in another. And each of these packages are analyzed by one instance of analysis server (approximately one IDE window?). The analysis root for the analysis server may be the monorepo, as you say.

[ookami-kb]

@srawlins yes, exactly. It's a monorepo (actually, even a workspace with 2 monorepos) opened in VS Code with dart pub get run for Dart packages and flutter packages get for Flutter packages.

[jacob314]

To over-communicate and recap what @srawlins and @bwilkerson wrote.

1. Until Flutter-specific pub cache causes issues flutter/flutter#53833 is resolved, you should not mix and match between flutter pub get and dart pub get within a mono-repo if you want the analyzer to be efficient. flutter pub get is completely fine to use for purely Dart packages. The issue you noticed impacts all Dart analyzer efficiency for your mono-repo project not just your plugin. The right fix is to resolve Flutter-specific pub cache causes issues flutter/flutter#53833, not to hack around it in the analyzer as there are cases where you could intentionally be referencing multiple conflicting versions of the same package from a mono-repo.
2. With the current analysis server plugin design, it is not possible to share much memory across analyzer plugins. Enabling significant reuse would require a significant change in how plugins supported either moving plugins into the main analyzer isolate or leveraging future enhancements to the Dart enabling sharing immutable objects across isolates.
3. For the case of different plugin versions, one thing we could do is display a user visible error if a project has multiple versions of the same plugin. If we did switch to a model of running analyzer plugins within the core analyzer isolate, we would not be able to support multiple plugin versions within a single analysis server.

[jacob314]

You can resolve the issue by specifying that you want exactly dart_code_metrics-4.*11.0* from everywhere you use the dart_code_metrics plugin. I would be very precise about what version you want to avoid an issue rather than accepting a version range.
To be clear dart_code_metrics-4.*10.1* and dart_code_metrics-4.*11.0* are different versions and will be treated like they are completely different plugins even if they are very similar.

[ookami-kb]

Yeah, that makes sense. Thanks!