I'm busy adding the ability to run the static analysis check of the flutter/plugins repo (and likely later, the flutter/packages repo) upstream, as part of a Dart CI pre-submit check. See dart-lang/sdk#46075 for general context (and flutter/plugins#3959 for some flutter/plugins specific work).

We like those pre-submit checks to run quickly. Currently it runs analysis for flutter/flutter, which takes perhaps 2 minutes to run. When trying out the CI analysis for flutter/plugins locally, it seem to run fairly slowly:

total time    : 334,763ms

options validation time  : 513ms
pub time      : 222,682ms
analysis time : 111,566ms

Generally, it takes 6 minutes to for the CI work, 4 of that spent running pub get, and 2 on analysis.

I haven't explored more deeply why things are slow, but some thoughts on potentially speeding them up:

• when running pub get, first check the timestamps of the pubspec.yaml file and the pubspec.lock file; if the lock file is the same age or younger theres no need to run pub get. (note that this would help w/ local builds but would not help in a CI situation)
• we're running pub get in a parent (package) dir as well as in sub-dirs, like in the example/ dir. we could instead copy the pubspec files for the package and sub-dirs, combine them logically, run pub get, and then copy the resulting pub artifacts back to the original dirs. This is similar to what flutter/flutter does for the whole repo. This would probably cut in half the number of pub get calls (but would change the resolved versions for some packages / example dirs)
• we run analysis for every package directory. we could instead move up a level and run analysis for every set of packages (a plugin, w/ the mac/windows/web package versions). this may or may not result in a speed increase - we'd run about 1/4 as many flutter analyze calls, but the analysis server already does a fair amount of caching of results

cc @stuartmorgan