mirror of
https://github.com/LadybirdBrowser/ladybird
synced 2026-04-26 01:35:08 +02:00
51758f3022
Generator::allocate_register used to scan the free pool to find the lowest-numbered register and then Vec::remove it, making every allocation O(n) in the size of the pool. When loading https://x.com/ on my Linux machine, we spent ~800ms in this function alone! This logic only existed to match the C++ register allocation ordering while transitioning from C++ to Rust in the LibJS compiler, so now we can simply get rid of it and make it instant. :^) So drop the "always hand out the lowest-numbered free register" policy and use the pool as a plain LIFO stack. Pushing and popping the back of the Vec are both O(1), and peak register usage is unchanged since the policy only affects which specific register gets reused, not how aggressively.
16 lines
616 B
Plaintext
16 lines
616 B
Plaintext
$bc2d85a0 string-from-char-code-builtin.js:3:1
|
|
Registers: 9
|
|
Blocks: 1
|
|
Constants:
|
|
[0] = Int32(65)
|
|
[1] = Int32(66)
|
|
|
|
block0:
|
|
[ 0] GetGlobal dst:reg6, `String`
|
|
[ 18] GetById dst:reg7, base:reg6, `fromCharCode` (String.fromCharCode)
|
|
[ 38] CallBuiltinStringFromCharCode dst:reg5, callee:reg7, this_value:reg6, argument:Int32(65), String.fromCharCode
|
|
[ 50] GetGlobal dst:reg6, `String`
|
|
[ 68] GetById dst:reg8, base:reg6, `fromCharCode` (String.fromCharCode)
|
|
[ 88] Call dst:reg7, callee:reg8, this_value:reg6, String.fromCharCode, arguments:[Int32(65), Int32(66)]
|
|
[ b0] End value:reg7
|