commit f391b0d3e74fdd71c6598f2963d616eed84fe96a
author Jens Johansen <jensj@google.com> Mon Aug 26 13:29:09 2024 +0000
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Mon Aug 26 13:29:09 2024 +0000
tree 707f3e599c563420352591276f234a96c073e216
parent c9d7e3a4f3a65984dc128597f5ca6e25409df0e6

[parser/CFE] Allow opting out of lazy strings; CFE opts out for body building

The scanner, when creating StringTokens cuts out the substring lazily if
their length is above some threshold. The work is then only done when
and if we actually need the string.

This makes sense for the cases where we normally do not need the string.

In the CFE we scan all sources twice: Once for building the outline, and
once for building the bodies.
When building the bodies we in almost always actually need the string
anyway (something along the lines of we don't ask for <400 out of over
400,000 when compiling the CFE itself).

This CL opts the CFEs second scan (when building bodies) out of the lazy
strings, copying the substrings up front, avoiding the creation of
intermediary `_LazySubstring` (`_CompactLazySubstring` /
`_FullLazySubstring`).

With an AOT compile of the CFE, compiling itself, 50 runs gives these
statistics:

```
msec task-clock:u: -1.3619% +/- 0.3329% (-57.88 +/- 14.15)
page-faults:u: -1.1453% +/- 0.0162% (-1163.82 +/- 16.44)
cycles:u: -1.4138% +/- 0.3433% (-248274774.52 +/- 60279949.79)
instructions:u: -0.5573% +/- 0.0003% (-120171914.10 +/- 59862.46)
branch-misses:u: -3.2906% +/- 1.4496% (-2192237.90 +/- 965762.85)
seconds time elapsed: -1.3662% +/- 0.3338% (-0.06 +/- 0.01)
seconds user: -1.3354% +/- 0.3715% (-0.05 +/- 0.01)
Scavenge(   new space) goes from 63 to 62
```

25 other runs gave these:

```
msec task-clock:u: -0.7929% +/- 0.4759% (-33.69 +/- 20.22)
page-faults:u: -1.1654% +/- 0.0176% (-1184.36 +/- 17.88)
cycles:u: -0.7756% +/- 0.5043% (-136122352.96 +/- 88506748.30)
instructions:u: -0.5578% +/- 0.0005% (-120265633.72 +/- 115062.27)
seconds time elapsed: -0.7852% +/- 0.4726% (-0.03 +/- 0.02)
Scavenge(   new space) goes from 63 to 62
```

So it seems likely that new space GCs go from 63 to 62, theat the
instruction count goes down by 0.55% and that it's actually around 1% faster.

Change-Id: Ic462a67db7274cc8ed38df7f3ed9f41f7497fc82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382162
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>