mirror of
https://github.com/RGBCube/serenity
synced 2025-05-21 00:35:08 +00:00
4fa5748093
This gives FunctionNode a "might need arguments object" boolean flag and
sets it based on the simplest possible heuristic for this: if we
encounter an identifier called "arguments" or "eval" up to the next
(nested) function declaration or expression, we won't need an arguments
object. Otherwise, we *might* need one - the final decision is made in
the FunctionDeclarationInstantiation AO.
Now, this is obviously not perfect. Even if you avoid eval, something
like `foo.arguments` will still trigger a false positive - but it's a
start and already massively cuts down on needlessly allocated objects,
especially in real-world code that is often minified, and so a full
"arguments" identifier will be an actual arguments object more often
than not.
To illustrate the actual impact of this change, here's the number of
allocated arguments objects during a full test-js run:
Before:
- Unmapped arguments objects: 78765
- Mapped arguments objects: 2455
After:
- Unmapped arguments objects: 18
- Mapped arguments objects: 37
This results in a ~5% speedup of test-js on my Linux host machine, and
about 3.5% on i686 Serenity in QEMU (warm runs, average of 5).
The following microbenchmark (calling an empty function 1M times) runs
25% faster on Linux and 45% on Serenity:
function foo() {}
for (var i = 0; i < 1_000_000; ++i)
foo();
test262 reports no changes in either direction, apart from a speedup :^)
|
||
|---|---|---|
| .. | ||
| Pass | ||
| ASTCodegen.cpp | ||
| BasicBlock.cpp | ||
| BasicBlock.h | ||
| Generator.cpp | ||
| Generator.h | ||
| Instruction.cpp | ||
| Instruction.h | ||
| Interpreter.cpp | ||
| Interpreter.h | ||
| Label.h | ||
| Op.cpp | ||
| Op.h | ||
| PassManager.h | ||
| Register.h | ||
| StringTable.cpp | ||
| StringTable.h | ||