Adds a new logging sink that supports an in-memory storage of events for
a subset of the whole server session. This is support for being able to
add 'start' and 'stop' buttons to the insight pages, which will allow
us and users to capture a smaller number of log entries.
Change-Id: Ia562e4da7b09c11ad9191c24cb85102970e1b116
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461901
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Changes the analyzer and related packages so that when they refer to
diagnostic constants, they do so via the import prefix `diag`, which
refers to the appropriate `diagnostic.dart` file containing the top
level diagnostic constant declarations, rather than the static
declarations inside `DiagnosticCode`-derived classes (which will soon
be removed).
This CL was created by the following steps:
- Run the script
`pkg/analyzer_utilities/tool/messages/switch_to_toplevel_diagnostics.dart`.
- Execute `dart fix --apply --code=unused_import,unnecessary_import`
on the following directories (this removes imports that are no
longer necessary due to the change):
- `pkg/analysis_server`
- `pkg/analyzer`
- `pkg/linter`
- `pkg/analysis_server_plugin`
- `pkg/analyzer_plugin`
- `pkg/analyzer_testing`
- `pkg/front_end`
- `pkg/analyzer_cli`
- Execute `dart format` on the following files and directories:
- `pkg/analysis_server`
- `pkg/analyzer`
- `pkg/linter`
- `pkg/analysis_server_plugin`
- `pkg/analyzer_plugin`
- `pkg/analyzer_testing`
- `pkg/front_end/test/scanner_test.dart`
(Note that `pkg/front_end` and `pkg/analyzer_cli` are not
re-formatted as whole directories because they contain `.dart` files
that are test cases rather than source code, and reformatting those
files might change test expectations.)
- Manually add `diag` to
pkg/front_end/test/spell_checking_list_tests.txt.
- Manually fix the ignore comment in
`pkg/analyzer_testing/lib/src/analysis_rule/pub_package_resolution.dart`. (The
script `switch_to_toplevel_diagnostics.dart` automatically adds it
after `import 'package:analyzer/src/diagnostic/diagnostic.dart' as
diag;`, but then executing `dart format` bumps the ignore comment to
the following line, where it has no effect.)
Change-Id: I6a6a69643022aab2b5a6224fb4124eead243260d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461521
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In the process of adding this support I decided to add a 'kind' field to
the entries so that it was easier to check to see what kind of entry the
player was suppose to deal with.
I also create constants for the keys used in entries to make it easier
to keep the logger and player consistent.
Change-Id: Ib1f57c8f9d28bcfad6cf9bb3c8c6ec74fcb17c8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461520
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Changes the constant `generateTopLevelConstants` from `false` to
`true`, which moves the generated constants for analyzer diagnostics
so that they are now top level constants inside files called
`diagnostic.g.dart`, rather than static constants inside
`DiagnosticCode`-derived classes such as `CompileTimeErrorCode`.
To avoid breaking code in the analyzer and related packages, the
constant declarations inside `DiagnosticCode`-derived classes still
exist, but they simply redirect to the constants in the new
`diagnostic.g.dart` files. The redirecting constants will be deleted
in a follow-up CL.
This CL was created by the following steps:
- Change the constant `generateTopLevelConstants` from `false` to
`true`.
- Re-run diagnostic code generation.
- Manually adjust imports in the parent libraries of the generated
files as needed to fix compile-time errors.
There are no other changes.
Change-Id: I6a6a6964f574bc9ff4ab74b2c6b218842991708b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461440
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Modifies the analyzer diagnostic message code generation logic so that
it's capable of generating diagnostic constants either:
- As static constants inside `DiagnosticCode`-derived classes such as
`CompileTimeErrorCode`
- Or as top level constants inside of new files called
`diagnostic.g.dart`.
The behavior is controlled through the constant
`generateTopLevelConstants`. This constant is currently `false`, which
means that diagnostic constants are still generated as static
constants inside `DiagnosticCode`-derived classes (as they have been
for quite some time). This CL introduces the new `diagnostic.g.dart`
files, but they are currently empty.
In a follow-up CL I will flip the flag to `true` and re-run the code
generation logic, and in a later CL, I'll remove the flag. The reason
for spreading the work across multiple CLs is twofold:
- To make code review easier
- To make merge conflicts easier to deal with (since the flag flip CL
can easily be regenerated if merge conflicts arise).
Note that when the flag is set to `true`, static constants will still
be generated to the `DiagnosticCode`-derived classes to avoid breaking
code in the analyzer and related packages, but these constants will
simply redirect to the constants in the new `diagnostic.g.dart` files.
Change-Id: I6a6a696452d1a81a45010b374e898f0fa5fe5c9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461260
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- wait for message to be completed and then set completed (this changes the order of messages in the listener, changes test results).
- do not put lsp.ResponseMessage on the queue (we never did, but were adding it to the listener)
- store the messages in the order received, compute the display json string on demand.
- keep track of pending and active messages when an incoming message goes on the pending queue, and when it moves to active.
Change-Id: Ife8246cdc92c5f81f9db7a7c11072ee647cd2bdc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/460902
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Refactors the diagnostic message generation logic, specifically the
logic for generating `// ignore_for_file:` comments. This logic is now
encapsulated in a single method,
`AnalyzerDiagnosticPackage.writeIgnoresTo`.
Also removes the logic for generating `// ignore_for_file:
deprecated_member_use_from_same_package` and `ignore_for_file:
constant_identifier_names`, which are no longer needed in any of these
generated files.
This paves the way for a follow-up CL that will introduce a new
generated file, ensuring that we won't have to duplicate this logic
when the new generated file is introduced.
Change-Id: I6a6a6964d0164244aa29b2a08dcca4c920f72e7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461143
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Changes the runtime types of the diagnostic message constants for the
analyzer from derived classes like `ParserErrorWithoutArguments`,
`ParserErrorTemplate`, or `ParserErrorCode` to the corresponding base
classes (`DiagnosticWithoutArgumentsImpl`, `DiagnosticWithArguments`,
or `DiagnosticCodeWithExpectedTypes`). The static types of the
constants are unchanged.
This allows the generated `...Template` classes (which derived from
`DiagnosticWithArguments`) and `...WithoutArguments` classes (which
used `DiagnosticWithoutArguments` as a mixin) to be removed.
Classes such as `ParserErrorCode`, `WarningCode`, etc. remain, but
they are now used solely as namespaces for the generated
constants. They will be removed in a later CL.
The runtime types of the diagnostic message constants for lints are
not changed. They remain `LinterLintWithoutArguments`,
`LinterLintTemplate`, and `LinterLintCode`, so that clients of the
analyzer public API can still identify lint codes by checking whether
they are subtypes of the public API class `LintCode`.
Change-Id: I6a6a69640886d560ba53a1b4351f634778d70db5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459500
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Replaces "is" tests that refer to classes derived from
`DiagnosticCode` with tests on `DiagnosticCode.type`:
- `x is ScannerErrorCode || x is ParserErrorCode` is replaced with
`x.type == DiagnosticType.SYNTACTIC_ERROR`. This is exactly
equivalent, because `ScannerErrorCode` and `ParserErrorCode` are the
only two `DiagnosticCode`-derived classes whose `type` method returns
`SYNTACTIC_ERROR`.
- `x is TodoCode` is replaced with `x.type ==
DiagnosticType.TODO`. This is exactly equivalent, because `TodoCode`
is the only `DiagnosticCode`-derived class whose `type` method
returns `TODO`.
- In `statement_completion.dart`, `x is! HintCode && x is!
WarningCode` is replaced with `x.type ==
DiagnosticType.SYNTACTIC_ERROR`. The new test is less accepting: for
example, it previously accepted diagnostics of type
`StaticWarningCode`. This test is used to short-cut the generation
of statement completions such as completing an incomplete `do`
statement. These completions are only necessary to generate if there
is a syntax error, so there should be no user-visible behavior
change.
- In `fix_processor.dart`, `x is LintCode || x is HintCode || x is
WarningCode` is replaced with `x.type == DiagnosticType.LINT ||
x.type == DiagnosticType.STATIC_WARNING`. The new test is more
accepting: it now accepts any diagnostic code whose type is
`STATIC_WARNING`, when previously it only accepted warnings of type
`WarningCode` (and rejected warnings of types like
`StaticWarningCode`). This test determines when quick fixes like
"ignore diagnostic on this line" are offered, so the behavior change
is appropriate.
- Also replaces a documentation reference to `TodoCode` (in
`todo_codes.dart`) with a reference to `DiagnosticType.TODO`.
These changes pave the way for a follow-up CL in which I plan to
eliminate these derived classes entirely.
Change-Id: I6a6a69647ff62dfe06b0219d8b292da53427cf0d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461140
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This removes all code related to handling requests for (and sending notifications of modifications of) the virtual files for macros.
Clients would never call this handler unless the analysis server had previously told them about these virtual files with the `dart-macro+file` scheme, which never happens because the implementation was previously removed.
This does not remove the `clientUriConverter` (which as well as handling conversions to/from the macro scheme, also handles conversions between URIs and Paths to support using URIs in the legacy protocol) because I'm not yet certain that is unused.
Change-Id: I148e2383a48b5f6e3a28eff3dd11506fc86353b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461120
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Removes nearly all of the special handling of `uniqueName` in
constructors in the `DiagnosticCode` class hierarchy.
With three exceptions, the value passed for the named parameter
`uniqueName` is the same as the value that will eventually be stored
in the `DiagnosticCode.uniqueName` field. The three exceptions are the
constructors for `LintCode` and `SecurityLintCode`, and the unnamed
constructor for `LinterLintCode`. These constructors allow
`uniqueName` to be `null`, and if `null` is supplied, they replace it
with `LintCode.$name`.
These exceptions are needed for analyzer API compatibility in the case
of `LintCode`, and for compatibility with google3 code in the case of
`SecurityLintCode` and `LinterLintCode`.
In follow-up CLs, I will be updating google3 code to make the
exceptions in `SecurityLintCode` and `LinterLintCode` unnecessary.
Change-Id: I6a6a6964d828c3a8db6563d47347d5ca8f550ac3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459001
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Changes the static types of the diagnostic message constants for the
analyzer (and linter) from derived classes like
`ParserErrorWithoutArguments`, `ParserErrorTemplate`, or
`ParserErrorCode` to the corresponding base classes
(`DiagnosticWithoutArguments`, `DiagnosticWithArguments`, or
`DiagnosticCode`). The actual runtime types of the constants is
unchanged.
This is a step toward simplifying the `DiagnosticCode` class
hierarchy.
Change-Id: I6a6a69643773adcf5834a9b9e3be90623611d4e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458961
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Eventually, the analyzer and front end will need to use the
corresponding public name as the effective name of the parameter. That
means that in addition to seeing if the parameter has a public name or
not, we actually need it. Instead of calculating the public name in the
parser and then plumbing it through the formal parameter listener, I
did the error reporting separately in the front end and analyzer.
Let me know if you think that makes sense. I can also move the other
private named parameters (back) out of the parser and into the two
front ends to be consistent if you want.
Change-Id: I9ca6c003b962d9b14d8dfa46eea4b31689935f04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458703
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
The session logger is the first half of the replay mechanism. It
captures data in a log about all of the messages sent to and from the
analysis server. The log player will then take such a log and replay
the portions required in order to drive an analysis server.
This first CL captures all of the communications except those with the
plugin isolates. Adding support for the plugin isolates will require
some additional refactoring that I thought would be easier to review if
placed in a separate CL.
Change-Id: I8f19abd3ebff83ac26584a9377922520857801d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459341
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
I tried to make it lowerCamelCase, but there are some generalized tests
in server_protocol_test.dart that make that... difficult. I decided to
punt it for later.
Change-Id: I5aff5a1b27cb6a281146fb0ed10578f1bd85be11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459241
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Adds the constructor parameter `uniqueNameCheck` to `DiagnosticCode`
and derived classes. If a non-null value is supplied for this
parameter, an assertion checks that it's equal to
`uniqueName`. (Passing a `null` value disables the assertion; this is
necessary to preserve analyzer API compatibility).
The reason for this change is that the value supplied for `uniqueName`
when calling constructors in the `DiagnosticCode` class hierarchy is
not necessarily the same as the value that is eventually stored in the
`uniqueName` field; it goes through a sequence of manipulations while
being passed up the superclass chain that make its actual behavior
difficult to follow. The `uniqueNameCheck` field allows me to test the
theory that the actual values that wind up in `uniqueName` are simply
the analyzer codes, with the exception that `LinterLintCode.` is
replaced with `LintCode.`.
In a follow-up CL, I plan to eliminate nearly all the manipulations of
`uniqueName` that occur while being passed up the superclass chain,
which will simplify the code generation logic for computing
`uniqueName` values. Adding `uniqueNameCheck` now allows me to test
out the new, simpler logic, and verify that it will produce the same
result as today's more complex logic.
The `uniqueNameCheck` parameter is marked as `@deprecated` to prevent
clients from trying to use it; this ensures that when I remove it in a
follow-up CL, it won't be necessary to bump the analyzer major
version.
Change-Id: I6a6a696440bce62a31b988d12064244e54e37b6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458820
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the constructors for `LintCodeWithExpectedTypes`, and the code
generated DiagnosticCode classes, so that all their constructor
parameters are named parameters.
This makes the classes in the `DiagnosticCode` hierarchy more uniform:
excluding test classes, the only remaining constructors that have
required positional parameters are now `LintCode` (which is part of
the analyzer public API and can't easily be changed), the unnamed
constructor for `LinterLintCode` (which is deprecated and will soon be
removed), and `SecurityLintCode` (which is used internally in google3
and will require more effort to change).
This change paves the way for follow-up CLs in which I will be
flattening the `DiagnosticCode` hierarchy; those follow-up CLs will
change which constructors are called by generated code, so it will be
easier to write and review them if they don't have to switch between
named and unnamed parameters.
Change-Id: I6a6a696432c8dc701fcd87a82350d185787f5d77
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459100
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes several references to derived diagnostic types
(`CompileTimeErrorCode`, `WarningCode`, etc.) to simply
`DiagnosticCode`.
This paves the way for a follow-up CL that will change the static
types of the generated analyzer diagnostic code objects to more
general types. This is part of a longer-term effort to simplify the
`DiagnosticCode` class hierarchy.
Change-Id: I6a6a69642561aebf2607e834fa09fa608cb4fa10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458587
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This class is the supertype for all concrete diagnostic classes in the
analyzer, analysis server, and linter, except for `LintCode` and some
mock classes used in tests. It provides a single common implementation
of the `severity` and `type` getters, which were previously duplicated
in a large number of code-generated derived classes.
This paves the way for follow-up CLs that will simplify the
DiagnosticCode type hierarchy, removing the code-generated derived
classes entirely.
Change-Id: I6a6a696408d1a1c51883a3a652c81ed8c9fe3cb3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458585
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Removes the field `GeneratedDiagnosticClassInfo.severity`. It always
matched the severity implied by the corresponding `type`, so it's
simpler and more uniform to simply base the severity on the type.
This paves the way for a follow-up CL in which I plan to move the
severity computation to a common base class.
Change-Id: I6a6a69646455fe015596d38168f7fce6f4b7eb86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458582
Reviewed-by: Samuel Rawlins <srawlins@google.com>
When processing a change request we have to construct the new content
for the changed file from the "diff" we receive. Before this CL we
calcualted a `LineInfo` to normally only use 1 entry in the list, then
calculated the new String, then calculated the new String once more.
This CL only gets the offset of the line we actually need (in what I
assume to be the normal case of only needing 1 line) and only calculates
the new string once for a reduction in processing time of about 50%.
For small files it probably wont matter much, but for bigger files it
will likely be noticeable.
To get the actual data in the benchmark this CL introduces `asJson` in
the timing pages, and picks out of the performance data the
"real number" for the change request. Turns out the overall number can
be very wrong because there's an async gap (where other stuff can be happening) between the calculation being done and the timing being
stopped.
Data:
Original -> Not doing the line starts:
Difference at 95.0% confidence
-284.7 +/- 35.8987
-33.0624% +/- 4.16893%
(Student's t, pooled s = 38.2065)
Not doing the line starts -> also not doing the newContent calculation twice:
Difference at 95.0% confidence
-207.2 +/- 31.3105
-35.9473% +/- 5.43207%
(Student's t, pooled s = 33.3233)
In total, i.e. from original -> this CL:
Difference at 95.0% confidence
-491.9 +/- 34.8949
-57.1246% +/- 4.05237%
(Student's t, pooled s = 37.1383)
This is with a size of 16,000 in the benchmark, but the processing should be linear so the ~57% decrease should be valid overall - although naturally in raw numbers it's not going to cut of ~half a second per 25 change requests in smaller files.
Raw data:
```
Original:
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":830,"size 16000: peak virtual memory size (kb)":2473160,"size 16000: total program size (virtual) (kb)":2309328,"size 16000: peak resident set size (\"high water mark\") (kb)":540228,"size 16000: size of memory portions (rss) (kb)":373328}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":938,"size 16000: peak virtual memory size (kb)":2365488,"size 16000: total program size (virtual) (kb)":2306336,"size 16000: peak resident set size (\"high water mark\") (kb)":509212,"size 16000: size of memory portions (rss) (kb)":438796}
{"size 16000: Initial analysis (ms)":7,"size 16000: Processing time for 25 change requests (ms)":900,"size 16000: peak virtual memory size (kb)":2354420,"size 16000: total program size (virtual) (kb)":2300740,"size 16000: peak resident set size (\"high water mark\") (kb)":496768,"size 16000: size of memory portions (rss) (kb)":443892}
{"size 16000: Initial analysis (ms)":9,"size 16000: Processing time for 25 change requests (ms)":803,"size 16000: peak virtual memory size (kb)":2296448,"size 16000: total program size (virtual) (kb)":2223740,"size 16000: peak resident set size (\"high water mark\") (kb)":503040,"size 16000: size of memory portions (rss) (kb)":431608}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":821,"size 16000: peak virtual memory size (kb)":2315888,"size 16000: total program size (virtual) (kb)":2158996,"size 16000: peak resident set size (\"high water mark\") (kb)":520212,"size 16000: size of memory portions (rss) (kb)":360704}
{"size 16000: Initial analysis (ms)":15,"size 16000: Processing time for 25 change requests (ms)":835,"size 16000: peak virtual memory size (kb)":2323752,"size 16000: total program size (virtual) (kb)":2215748,"size 16000: peak resident set size (\"high water mark\") (kb)":534380,"size 16000: size of memory portions (rss) (kb)":416532}
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":848,"size 16000: peak virtual memory size (kb)":2349108,"size 16000: total program size (virtual) (kb)":2219696,"size 16000: peak resident set size (\"high water mark\") (kb)":469712,"size 16000: size of memory portions (rss) (kb)":361812}
{"size 16000: Initial analysis (ms)":7,"size 16000: Processing time for 25 change requests (ms)":870,"size 16000: peak virtual memory size (kb)":2288416,"size 16000: total program size (virtual) (kb)":2204484,"size 16000: peak resident set size (\"high water mark\") (kb)":486716,"size 16000: size of memory portions (rss) (kb)":396940}
{"size 16000: Initial analysis (ms)":9,"size 16000: Processing time for 25 change requests (ms)":895,"size 16000: peak virtual memory size (kb)":2280008,"size 16000: total program size (virtual) (kb)":2188336,"size 16000: peak resident set size (\"high water mark\") (kb)":476664,"size 16000: size of memory portions (rss) (kb)":398232}
{"size 16000: Initial analysis (ms)":18,"size 16000: Processing time for 25 change requests (ms)":871,"size 16000: peak virtual memory size (kb)":2281128,"size 16000: total program size (virtual) (kb)":2216500,"size 16000: peak resident set size (\"high water mark\") (kb)":477080,"size 16000: size of memory portions (rss) (kb)":426856}
No line starts:
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":633,"size 16000: peak virtual memory size (kb)":2279560,"size 16000: total program size (virtual) (kb)":2169640,"size 16000: peak resident set size (\"high water mark\") (kb)":467740,"size 16000: size of memory portions (rss) (kb)":365508}
{"size 16000: Initial analysis (ms)":9,"size 16000: Processing time for 25 change requests (ms)":578,"size 16000: peak virtual memory size (kb)":2481552,"size 16000: total program size (virtual) (kb)":2307804,"size 16000: peak resident set size (\"high water mark\") (kb)":547824,"size 16000: size of memory portions (rss) (kb)":370972}
{"size 16000: Initial analysis (ms)":6,"size 16000: Processing time for 25 change requests (ms)":568,"size 16000: peak virtual memory size (kb)":2412752,"size 16000: total program size (virtual) (kb)":2301564,"size 16000: peak resident set size (\"high water mark\") (kb)":546168,"size 16000: size of memory portions (rss) (kb)":447020}
{"size 16000: Initial analysis (ms)":5,"size 16000: Processing time for 25 change requests (ms)":530,"size 16000: peak virtual memory size (kb)":2426432,"size 16000: total program size (virtual) (kb)":2364240,"size 16000: peak resident set size (\"high water mark\") (kb)":565100,"size 16000: size of memory portions (rss) (kb)":503364}
{"size 16000: Initial analysis (ms)":12,"size 16000: Processing time for 25 change requests (ms)":620,"size 16000: peak virtual memory size (kb)":2276668,"size 16000: total program size (virtual) (kb)":2226296,"size 16000: peak resident set size (\"high water mark\") (kb)":477488,"size 16000: size of memory portions (rss) (kb)":434240}
{"size 16000: Initial analysis (ms)":12,"size 16000: Processing time for 25 change requests (ms)":534,"size 16000: peak virtual memory size (kb)":2391200,"size 16000: total program size (virtual) (kb)":2349392,"size 16000: peak resident set size (\"high water mark\") (kb)":531700,"size 16000: size of memory portions (rss) (kb)":490400}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":588,"size 16000: peak virtual memory size (kb)":2377112,"size 16000: total program size (virtual) (kb)":2278476,"size 16000: peak resident set size (\"high water mark\") (kb)":518740,"size 16000: size of memory portions (rss) (kb)":412952}
{"size 16000: Initial analysis (ms)":10,"size 16000: Processing time for 25 change requests (ms)":589,"size 16000: peak virtual memory size (kb)":2373204,"size 16000: total program size (virtual) (kb)":2258000,"size 16000: peak resident set size (\"high water mark\") (kb)":516188,"size 16000: size of memory portions (rss) (kb)":390972}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":583,"size 16000: peak virtual memory size (kb)":2349184,"size 16000: total program size (virtual) (kb)":2206488,"size 16000: peak resident set size (\"high water mark\") (kb)":555888,"size 16000: size of memory portions (rss) (kb)":404356}
{"size 16000: Initial analysis (ms)":9,"size 16000: Processing time for 25 change requests (ms)":541,"size 16000: peak virtual memory size (kb)":2335140,"size 16000: total program size (virtual) (kb)":2227132,"size 16000: peak resident set size (\"high water mark\") (kb)":540204,"size 16000: size of memory portions (rss) (kb)":433256}
Additionally don't do it twice:
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":379,"size 16000: peak virtual memory size (kb)":2274520,"size 16000: total program size (virtual) (kb)":2197944,"size 16000: peak resident set size (\"high water mark\") (kb)":470816,"size 16000: size of memory portions (rss) (kb)":393124}
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":431,"size 16000: peak virtual memory size (kb)":2353820,"size 16000: total program size (virtual) (kb)":2287616,"size 16000: peak resident set size (\"high water mark\") (kb)":494148,"size 16000: size of memory portions (rss) (kb)":428836}
{"size 16000: Initial analysis (ms)":15,"size 16000: Processing time for 25 change requests (ms)":334,"size 16000: peak virtual memory size (kb)":2210904,"size 16000: total program size (virtual) (kb)":2164796,"size 16000: peak resident set size (\"high water mark\") (kb)":472180,"size 16000: size of memory portions (rss) (kb)":437368}
{"size 16000: Initial analysis (ms)":16,"size 16000: Processing time for 25 change requests (ms)":364,"size 16000: peak virtual memory size (kb)":2284260,"size 16000: total program size (virtual) (kb)":2239292,"size 16000: peak resident set size (\"high water mark\") (kb)":482420,"size 16000: size of memory portions (rss) (kb)":437232}
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":397,"size 16000: peak virtual memory size (kb)":2148164,"size 16000: total program size (virtual) (kb)":2118072,"size 16000: peak resident set size (\"high water mark\") (kb)":479676,"size 16000: size of memory portions (rss) (kb)":446752}
{"size 16000: Initial analysis (ms)":5,"size 16000: Processing time for 25 change requests (ms)":327,"size 16000: peak virtual memory size (kb)":2292012,"size 16000: total program size (virtual) (kb)":2269972,"size 16000: peak resident set size (\"high water mark\") (kb)":487932,"size 16000: size of memory portions (rss) (kb)":476524}
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":339,"size 16000: peak virtual memory size (kb)":2348844,"size 16000: total program size (virtual) (kb)":2286660,"size 16000: peak resident set size (\"high water mark\") (kb)":484112,"size 16000: size of memory portions (rss) (kb)":432036}
{"size 16000: Initial analysis (ms)":16,"size 16000: Processing time for 25 change requests (ms)":393,"size 16000: peak virtual memory size (kb)":2277080,"size 16000: total program size (virtual) (kb)":2248636,"size 16000: peak resident set size (\"high water mark\") (kb)":472864,"size 16000: size of memory portions (rss) (kb)":440092}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":365,"size 16000: peak virtual memory size (kb)":2397828,"size 16000: total program size (virtual) (kb)":2201648,"size 16000: peak resident set size (\"high water mark\") (kb)":530176,"size 16000: size of memory portions (rss) (kb)":334264}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":363,"size 16000: peak virtual memory size (kb)":2286312,"size 16000: total program size (virtual) (kb)":2253760,"size 16000: peak resident set size (\"high water mark\") (kb)":480004,"size 16000: size of memory portions (rss) (kb)":464720}
```
Change-Id: If122d4667da677fc07cab83ae97135d3a7ac99d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/457722
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
* Bump kept requests from 50 to 250
* Make the request storage (`RecentBuffer`) add in constant time instead
of linear time (modulo the `n` in `O(n)` being the constant 50 or 250
making the before theoretically constant too, but anyway).
Change-Id: Ib00bd038b06f167fd7298a87402a89a23fd53880
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/457025
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Konstantin Shcheglov