dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibJS/SourceCode.h

66 lines
2.3 KiB
C
Raw Normal View History

LibJS: Reduce AST memory usage by shrink-wrapping source range info 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!) :^)
2022-11-21 13:37:38 -03:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2022-2023, Andreas Kling <andreas@ladybird.org>
LibJS: Reduce AST memory usage by shrink-wrapping source range info 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!) :^)
2022-11-21 13:37:38 -03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
#include <AK/ByteString.h>
LibJS+LibWeb: Keep cached script source text lazy Avoid decoding warm-cache script responses into full UTF-16 SourceCode buffers when a bytecode cache sidecar is available. SourceCode now keeps the original immutable source bytes and source encoding, then decodes only when full source text or a Function.toString() range is requested. Compute the bytecode cache source hash while streaming decoded code points from the response bytes, so cache validation does not force an intermediate UTF-8 string. Function and class source text metadata now stores SourceCode ranges instead of views into a materialized buffer.
2026-05-17 14:54:58 -03:00
#include <AK/Optional.h>
LibJS: Port the JS lexer and parser to UTF-16 This ports the lexer to UTF-16 and deals with the immediate fallout up to the AST. The AST will be dealt with in upcoming commits. The lexer will still accept UTF-8 strings as input, and will transcode them to UTF-16 for lexing. This doesn't actually incur a new allocation, as we were already converting the input StringView to a ByteString for each lexer. One immediate logical benefit here is that we do not need to know off- hand how many UTF-8 bytes some special code points occupy. They all happen to be a single UTF-16 code unit. So instead of advancing the lexer by 3 positions in some cases, we can just always advance by 1.
2025-08-06 08:18:45 -03:00
#include <AK/Utf16String.h>
LibJS: Make Error stack trace generation faster with a line break cache Generating Error objects got a lot slower after the introduction of SourceCode in b0b022507b2f73be2f4cef17deb8ece91dae6822. 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.
2022-11-24 10:16:56 -03:00
#include <AK/Vector.h>
LibJS+LibWeb: Keep cached script source text lazy Avoid decoding warm-cache script responses into full UTF-16 SourceCode buffers when a bytecode cache sidecar is available. SourceCode now keeps the original immutable source bytes and source encoding, then decodes only when full source text or a Function.toString() range is requested. Compute the bytecode cache source hash while streaming decoded code points from the response bytes, so cache validation does not force an intermediate UTF-8 string. Function and class source text metadata now stores SourceCode ranges instead of views into a materialized buffer.
2026-05-17 14:54:58 -03:00
#include <LibCore/ImmutableBytes.h>
LibJS: Enable EXPLICIT_SYMBOL_EXPORT and annotate minimum symbol set
2025-07-19 17:49:30 -03:00
#include <LibJS/Export.h>
LibJS: Reduce AST memory usage by shrink-wrapping source range info 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!) :^)
2022-11-21 13:37:38 -03:00
#include <LibJS/Forward.h>
LibJS: Make line-and-column resolution fast for large minified JS 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.
2023-09-12 08:03:56 -03:00
#include <LibJS/Position.h>
LibJS: Reduce AST memory usage by shrink-wrapping source range info 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!) :^)
2022-11-21 13:37:38 -03:00
namespace JS {
LibJS: Enable EXPLICIT_SYMBOL_EXPORT and annotate minimum symbol set
2025-07-19 17:49:30 -03:00
class JS_API SourceCode : public RefCounted<SourceCode> {
LibJS: Reduce AST memory usage by shrink-wrapping source range info 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!) :^)
2022-11-21 13:37:38 -03:00
public:
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
static NonnullRefPtr<SourceCode const> create(Utf16String filename, Utf16String code);
static NonnullRefPtr<SourceCode const> create(Utf16String filename, size_t length_in_code_units, ByteString source_encoding, Core::ImmutableBytes source_bytes);
LibJS: Reduce AST memory usage by shrink-wrapping source range info 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!) :^)
2022-11-21 13:37:38 -03:00
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
Utf16String const& filename() const { return m_filename; }
LibJS+LibWeb: Keep cached script source text lazy Avoid decoding warm-cache script responses into full UTF-16 SourceCode buffers when a bytecode cache sidecar is available. SourceCode now keeps the original immutable source bytes and source encoding, then decodes only when full source text or a Function.toString() range is requested. Compute the bytecode cache source hash while streaming decoded code points from the response bytes, so cache validation does not force an intermediate UTF-8 string. Function and class source text metadata now stores SourceCode ranges instead of views into a materialized buffer.
2026-05-17 14:54:58 -03:00
Utf16String const& code() const;
Utf16View const& code_view() const;
LibJS: Cache length-in-code-units in SourceCode This avoids some bit twiddling whenever accessing the length in code units in the lexer.
2025-11-08 18:57:01 -03:00
size_t length_in_code_units() const { return m_length_in_code_units; }
LibJS: Reduce AST memory usage by shrink-wrapping source range info 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!) :^)
2022-11-21 13:37:38 -03:00
LibJS: Cache ASCII-to-UTF-16 source conversion for Rust compilation The Rust FFI requires UTF-16 source data, so ASCII-stored source code must be widened to UTF-16. Previously, this conversion was done into a temporary buffer on every call to compile_function, meaning the entire source file was converted for each lazily-compiled function. For large modules with many functions, this caused heavy spinning. Move the conversion into SourceCode::utf16_data() which lazily converts and caches the result once per source file. Subsequent compilations of functions from the same file reuse the cached data.
2026-02-24 18:07:27 -03:00
u16 const* utf16_data() const;
LibJS+LibWeb: Keep cached script source text lazy Avoid decoding warm-cache script responses into full UTF-16 SourceCode buffers when a bytecode cache sidecar is available. SourceCode now keeps the original immutable source bytes and source encoding, then decodes only when full source text or a Function.toString() range is requested. Compute the bytecode cache source hash while streaming decoded code points from the response bytes, so cache validation does not force an intermediate UTF-8 string. Function and class source text metadata now stores SourceCode ranges instead of views into a materialized buffer.
2026-05-17 14:54:58 -03:00
Utf16String source_text_from_offsets(size_t start_offset, size_t length) const;
LibJS: Cache ASCII-to-UTF-16 source conversion for Rust compilation The Rust FFI requires UTF-16 source data, so ASCII-stored source code must be widened to UTF-16. Previously, this conversion was done into a temporary buffer on every call to compile_function, meaning the entire source file was converted for each lazily-compiled function. For large modules with many functions, this caused heavy spinning. Move the conversion into SourceCode::utf16_data() which lazily converts and caches the result once per source file. Subsequent compilations of functions from the same file reuse the cached data.
2026-02-24 18:07:27 -03:00
LibJS: Reduce AST memory usage by shrink-wrapping source range info 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!) :^)
2022-11-21 13:37:38 -03:00
SourceRange range_from_offsets(u32 start_offset, u32 end_offset) const;
private:
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
SourceCode(Utf16String filename, Utf16String code);
SourceCode(Utf16String filename, size_t length_in_code_units, ByteString source_encoding, Core::ImmutableBytes source_bytes);
LibJS+LibWeb: Keep cached script source text lazy Avoid decoding warm-cache script responses into full UTF-16 SourceCode buffers when a bytecode cache sidecar is available. SourceCode now keeps the original immutable source bytes and source encoding, then decodes only when full source text or a Function.toString() range is requested. Compute the bytecode cache source hash while streaming decoded code points from the response bytes, so cache validation does not force an intermediate UTF-8 string. Function and class source text metadata now stores SourceCode ranges instead of views into a materialized buffer.
2026-05-17 14:54:58 -03:00
void ensure_code() const;
Utf16String decode_source_range(size_t start_offset, size_t length) const;
LibJS: Avoid repeated lazy source decoding Function.prototype.toString() can ask for the same cached function source text repeatedly after a script was materialized from the bytecode cache. In that path SourceCode still owns only the encoded source bytes, so every request decoded the requested source range again. Large ASCII bundles made that path expensive enough to stall Speedometer 2.1's Ember debug test. Keep the byte-backed SourceCode representation lazy, but let ASCII UTF-8 source ranges slice the source bytes directly. For other ASCII byte-backed encodings, first ask the decoder to prove that the source bytes map to the same UTF-16 code units at the same positions. Cache extracted function source text on shared function data after the first request so repeated toString() calls do not keep going back to SourceCode. Add bytecode cache coverage for toString() on lazy UTF-8 source bytes, keep malformed UTF-8 and UTF-16 edge cases on the decoder path, and cover PDFDocEncoding bytes that are not identity-mapped.
2026-05-19 08:59:58 -03:00
bool source_bytes_can_be_sliced_by_code_unit_offsets() const;
LibJS: Lazily map UTF-8 source offsets Avoid repeatedly decoding an entire byte-backed UTF-8 source when a cached function asks for its source text and the script contains a non-ASCII code point before the requested range. Build a small map from UTF-16 code unit offsets to byte offsets on demand for valid UTF-8 sources, then slice the source bytes directly for subsequent extractions. Invalid or non-UTF-8 sources keep using the existing decoder fallback. Add coverage for lazy range extraction after non-ASCII UTF-8 and for bytecode-cache materialization of function source text from such a script.
2026-05-19 10:56:55 -03:00
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
Utf16String m_filename;
LibJS+LibWeb: Keep cached script source text lazy Avoid decoding warm-cache script responses into full UTF-16 SourceCode buffers when a bytecode cache sidecar is available. SourceCode now keeps the original immutable source bytes and source encoding, then decodes only when full source text or a Function.toString() range is requested. Compute the bytecode cache source hash while streaming decoded code points from the response bytes, so cache validation does not force an intermediate UTF-8 string. Function and class source text metadata now stores SourceCode ranges instead of views into a materialized buffer.
2026-05-17 14:54:58 -03:00
Optional<Utf16String> mutable m_code;
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
ByteString m_source_encoding;
LibJS+LibWeb: Keep cached script source text lazy Avoid decoding warm-cache script responses into full UTF-16 SourceCode buffers when a bytecode cache sidecar is available. SourceCode now keeps the original immutable source bytes and source encoding, then decodes only when full source text or a Function.toString() range is requested. Compute the bytecode cache source hash while streaming decoded code points from the response bytes, so cache validation does not force an intermediate UTF-8 string. Function and class source text metadata now stores SourceCode ranges instead of views into a materialized buffer.
2026-05-17 14:54:58 -03:00
Core::ImmutableBytes mutable m_source_bytes;
Utf16View mutable m_code_view;
LibJS: Cache length-in-code-units in SourceCode This avoids some bit twiddling whenever accessing the length in code units in the lexer.
2025-11-08 18:57:01 -03:00
size_t m_length_in_code_units { 0 };
LibJS: Make Error stack trace generation faster with a line break cache Generating Error objects got a lot slower after the introduction of SourceCode in b0b022507b2f73be2f4cef17deb8ece91dae6822. 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.
2022-11-24 10:16:56 -03:00
LibJS: Make line-and-column resolution fast for large minified JS 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.
2023-09-12 08:03:56 -03:00
// For fast mapping of offsets to line/column numbers, we build a list of
// starting points (with byte offsets into the source string) and which
// line:column they map to. This can then be binary-searched.
void fill_position_cache() const;
LibJS: Drop source ranges from bytecode source maps Store source map locations as bytecode offset, line, and column. Runtime consumers only emit the start line and column, so source end positions and source text offsets do not need to be carried through Executable source maps, bytecode cache serialization, or the Rust FFI. Keep SourceCode's internal position cache able to track source text offsets so callers can still translate source offsets to line and column pairs when needed. Hash dump-bytecode IDs from the name, first source position, and bytecode size instead of source slices that need end offsets. Bump the bytecode cache format version for the slimmer serialized source map entry shape.
2026-05-14 03:29:39 -03:00
struct CachedPosition {
Position position;
u32 offset { 0 };
};
Vector<CachedPosition> mutable m_cached_positions;
LibJS: Cache ASCII-to-UTF-16 source conversion for Rust compilation The Rust FFI requires UTF-16 source data, so ASCII-stored source code must be widened to UTF-16. Previously, this conversion was done into a temporary buffer on every call to compile_function, meaning the entire source file was converted for each lazily-compiled function. For large modules with many functions, this caused heavy spinning. Move the conversion into SourceCode::utf16_data() which lazily converts and caches the result once per source file. Subsequent compilations of functions from the same file reuse the cached data.
2026-02-24 18:07:27 -03:00
// Cached UTF-16 widening of ASCII source data, lazily populated by
// utf16_data() for use by the Rust compilation pipeline.
Vector<u16> mutable m_utf16_data_cache;
LibJS: Avoid repeated lazy source decoding Function.prototype.toString() can ask for the same cached function source text repeatedly after a script was materialized from the bytecode cache. In that path SourceCode still owns only the encoded source bytes, so every request decoded the requested source range again. Large ASCII bundles made that path expensive enough to stall Speedometer 2.1's Ember debug test. Keep the byte-backed SourceCode representation lazy, but let ASCII UTF-8 source ranges slice the source bytes directly. For other ASCII byte-backed encodings, first ask the decoder to prove that the source bytes map to the same UTF-16 code units at the same positions. Cache extracted function source text on shared function data after the first request so repeated toString() calls do not keep going back to SourceCode. Add bytecode cache coverage for toString() on lazy UTF-8 source bytes, keep malformed UTF-8 and UTF-16 edge cases on the decoder path, and cover PDFDocEncoding bytes that are not identity-mapped.
2026-05-19 08:59:58 -03:00
Optional<bool> mutable m_source_bytes_can_be_sliced_by_code_unit_offsets;
LibJS: Reduce AST memory usage by shrink-wrapping source range info 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!) :^)
2022-11-21 13:37:38 -03:00
};
}
Reference in a new issue Copy permalink