There's no direct relation between WebStorm's indexing and 'Dart
Analysis...' progress. Those are separate processes that do not
wait for each other. Let me clarify how it works and check if it
is not the case in your environment.
IDE's indexing starts when:
- New project created or IDE has been updated (one-time
indexing)
- A lot of new files appear or change in project (for example
git branch switch)
- Project roots change (for example SDK changed or 'pub
upgrade'
Indexing should be fast (for example on SDK switch it takes
just a few seconds to index new Dart SDK).
In other cases indexing should not start and definitely should
not take much time. Reindexing should not happen on project
reopening. If it is not the case for you please describe the use
case and see instructions below. Issues with indexing are
handled by JetBrains.
'Dart Analysis...' progress shows status of the Dart
Analysis Server that is a part of the Dart SDK. It doesn't save
caches, so full analysis is redone each time when you reopen
your project. It shouldn't take ages on project opening, and
shouldn't take any significant time while you work with project
(after initial analysis completion). Issues with Analysis Server
are handled by the Google Dart team.
First steps that can help to track down performance issues
in the IDE. Issues can be reported to
YouTrack.
1. More details on what is slow and how is it slow and also
overview of the project structure (ideally - a sample project to
reproduce).
2. IDE logs and thread dumps (Help | Show Log, thread dumps are
also there)
3. CPU snapshot, see
instructions.
To track down issues with Analysis Server you can do the
following (issues can be reported to
https://github.com/dart-lang/sdk/issues):
In the IDE click Help | Find Action, type 'Registry', open it,
find 'dart.server.additional.arguments' registry option and
include something like this there:
--instrumentation-log-file=/Users/some/path/das_log.txt
Note that this log will contain the content of every file read by
the server, the file paths of those files, and possibly other
sensitive data. You should not send this file if you’ve been
working on confidential or proprietary code. Instead, we would
encourage you to try to reproduce your problem using an open
source code base and then send us the log from that session.
If you do choose to send us a log file containing confidential
code, please send it to a team member directly. Do not attach it
to an issue in the Github issue tracker or a posting to a public
forum.
Because these files can become quite large, the server will
periodically break the file into smaller pieces (by appending a
digit to the end of the file name). It will only keep the last 10
files, but it might be useful for us to get more than one of the
files that were written.
Regards,
Alex