-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Size of parser stack items makes parsing slow #10
Comments
Current status:
This 25% size reduction equated to a 10% runtime reduction, when running on all 7 EoSD ECL files. (note: WSL 2, files stored on NTFS) This "black magic and sorcery" actually makes it quite difficult to reason about things. I might consider sticking some boxes into Stmt instead... |
Boxing I made all Stmt-producing productions return Unfortunately the runtime performance did not change from what it is currently. Doing this required me to write this travesty in place of what used to be #[inline]
SpStmts0: Vec<Sp<ast::Stmt>> = {
=> vec![],
SpStmts1,
};
SpStmts1: Vec<Sp<ast::Stmt>> = {
<stmt:Sp<BoxStmt>> => vec![sp!(stmt.span => *stmt.value)],
<stmts:SpStmts1> <stmt:Sp<BoxStmt>> => util::push(stmts, sp!(stmt.span => *stmt.value)),
}; An aside: It looks like inline rules in the grammar still generate states that are placed on the stack. I discovered this when I tried to clean up the above code using the following so that I could write // NOTE: pub type UnboxType<T> = <T as core::ops::Deref>::Target;
#[inline]
Unbox<Rule>: util::UnboxType<Rule> = <r:Rule> => *r; Unfortunately despite the Variant102(util::UnboxType<Box<ast::Stmt>>), |
I tried replacing the boxes with a This still had no effect. This seems paradoxical. It would leads me to believe that it is perhaps not the size of the Symbol enum that is the problem, but rather the size of the ast structs in general (including Stmt). But, were that the case, then the loop desugaring/decompilation passes should show up much more on here... I don't know. Relavant branches: |
One item that appears on benchmarks (currently measuring about 8% on
anm-benchmark
forth15/title.anm
) is memcpy calls inlalrparser::__parse__Anything::__reduce
:After some digging in binja and CE, it appears that the majority of
memcpy
samples counted were likely in these calls to__symbols.pop()
:These
(Location, Symbol, Location)
tuples are currently 256 bytes large.__Symbol
is a union of all kinds of nonterminal:It's 256 bytes because Stmts are currently 208 bytes. (then there's the 8-byte discriminant in AnythingValue, the 16 bytes added by Sp<...>, another 8 bytes for __Symbol's discriminant, then 8 bytes for each Location).
We could probably speed things up a little bit by making
Stmt
smaller. I'm not sure how much we can do effectively short term aside from boxing some things, which has it's own cost; in the long term, arenas may help. Also, It would be fantabulous if we could figure out how to fix Spans to only be 8 bytes instead of an awkwardly-padded 12.More importantly, in the meanwhile.... we want to be careful about letting
Stmt
grow any bigger.The text was updated successfully, but these errors were encountered: