Given `{1, 2, 2, 2, 2, 2, 2, 3}` and the needle being `2`, the function
used to return the first matching element that it found (at index 3). It
now continues the search until it founds the first one, here at index 1.
Note that one side effect of that change is that when the binary search
fails, `nearby_index` now gives you the index right after instead of the
one before. The changes in LibJS and LibWeb are needed because of that.
Co-authored-by: Nico Weber <[email protected]>
The source code position cache was moved from a line based approach
to a "chunk"-based approach to improve performance on large, minified
JavaScript files with few lines, but this has had an adverse effect
on _multi-line_ source files.
Reintroduce some of the old behaviour by caching lines again, with
some added sanity limits to avoid caching empty/overly small lines.
Source code positions in files with few lines will still be cached
less often, since minified JavaScript files can be assumed to be
unusually large, and since stack traces for minified JavaScript
are less useful as well.
On WPT tests with large JavaScript dependencies like
`css/css-masking/animations/clip-interpolation.html` this reduces the
amount of time spent in `SourceCode::range_from_offsets` by as much as
99.98%, for the small small price of 80KB extra memory usage.
(cherry picked from commit 1b3f8e1e9ad14f0777188bd6eba06e42ffd98961)
Instead of caching start-of-line offsets, we now cache byte offsets
at regular intervals. This fixes an issue where we had terrible
performance on large minified JS, since that often means one very,
VERY long line (with no line endings to cache).
My machine was spending ~35ms per stack frame when throwing errors
on some heavy minified websites, and after this patch, we now spend
<1ms per stack frame.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Turns out we have to be a little more lenient when dealing with the
slightly hostile inputs in tests262-parser-tests.
This fix papers over some problematic situations by returning a fallback
range if we can't figure out exactly where an error occurred.
I've added a FIXME about returning nicer values.
Generating Error objects got a lot slower after the introduction of
SourceCode in b0b022507b.
This was noticeable with `test-js` which generates a lot of errors,
so walking the source code over and over to compute (line, column)
was eating a ton of time.
This patch makes repeated lookups a lot faster by building a cache
of line break offsets in the source code. The cache is built on first
offset lookup, so we only pay for this in code that actually throws.
On my machine, this takes `test-js` runtime from 6.7 sec to 4.3 sec.
Before this change, each AST node had a 64-byte SourceRange member.
This SourceRange had the following layout:
filename: StringView (16 bytes)
start: Position (24 bytes)
end: Position (24 bytes)
The Position structs have { line, column, offset }, all members size_t.
To reduce memory consumption, AST nodes now only store the following:
source_code: NonnullRefPtr<SourceCode> (8 bytes)
start_offset: u32 (4 bytes)
end_offset: u32 (4 bytes)
SourceCode is a new ref-counted data structure that keeps the filename
and original parsed source code in a single location, and all AST nodes
have a pointer to it.
The start_offset and end_offset can be turned into (line, column) when
necessary by calling SourceCode::range_from_offsets(). This will walk
the source code string and compute line/column numbers on the fly, so
it's not necessarily fast, but it should be rare since this information
is primarily used for diagnostics and exception stack traces.
With this, ASTNode shrinks from 80 bytes to 32 bytes. This gives us a
~23% reduction in memory usage when loading twitter.com/awesomekling
(330 MiB before, 253 MiB after!) :^)
Lucas CHOLLET