You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Same problem as #35, but difference is that once strings/Atoms are generated, they're immutable. So there's a simpler solution:
Assume we're going to create our own arena allocator.
Fill the allocator from both ends:
Fill from end for AST nodes (bumping downwards, same as bumpalo does).
Fill from start for strings (bumping upwards).
Same sort of idea as how heap grows upwards, and stack grows downwards.
We only build 1 string at a time, so can always grow strings in place while building them. This avoids memory fragmentation, and unused gaps in arena.
Side benefit: All string data in one place means AST transfer can convert all strings from UTF8 to UTF16 in one go (still complicated due to needing UTF16 indexes to slice that string, but it's a step in right direction).
The text was updated successfully, but these errors were encountered:
overlookmotel
changed the title
BuildStrings without repeated re-allocation and copies
Build strings without repeated re-allocation and copies
Jun 6, 2024
Same problem as #35, but difference is that once strings/
Atom
s are generated, they're immutable. So there's a simpler solution:Assume we're going to create our own arena allocator.
Fill the allocator from both ends:
Same sort of idea as how heap grows upwards, and stack grows downwards.
We only build 1 string at a time, so can always grow strings in place while building them. This avoids memory fragmentation, and unused gaps in arena.
Side benefit: All string data in one place means AST transfer can convert all strings from UTF8 to UTF16 in one go (still complicated due to needing UTF16 indexes to slice that string, but it's a step in right direction).
The text was updated successfully, but these errors were encountered: