Move most opts to runtime
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- javascript, rust
- Domain
- compilers, performance
Research direction
No files or tests are named. Start by reading the JIT and the dash_typed_cfg crate to understand how bytecode type information and the control-flow graph are produced; then identify which compile-time optimizations are candidates for runtime handling. Done means most optimizations use runtime information while constant propagation remains at compile time.
Written by the indexing model from the issue text.
Description
Currently dash tries to apply some optimizations at compile time, e.g. given
for (let i = 0; i < 1000; i++);
The comparison and increment get special opcodes that are faster than the generic cmp/inc opcodes as it skips the type check and is optimized specifically to work with integers.
However, doing this statically is very limited and leads to many missed optimizations.
It would be better if we applied these at runtime since we have far more information at runtime as it executes the code.
We already have some amount of infrastructure required for doing this from the JIT, namely the dash_typed_cfg crate for getting a CFG with type information from bytecode, which should already allow for some really nice optimizations that we couldn't do at compile time.
Opts like constant propagation should still run at compile time since there isn't any benefit to not doing it right away.
- Dominant language
- Rust
- Stars
- 54
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from y21/dash
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
`parseInt(x, undefined)` and `parseInt(x, null)` should be treated as if they were `parseInt(x, 10)` Open
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 58/100
-
AST
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
A-rt bug
Difficulty 3/5 1-2 days Newbie friendliness 35/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100