-
Notifications
You must be signed in to change notification settings - Fork 77
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
getVariable is an efficiency hotspot #1639
Comments
I've also run the parser generator through the profiler:
Looks like we should rewrite this rascal/src/org/rascalmpl/library/Node.rsc Lines 151 to 153 in fa8b7d2
|
Here is a repo case: import Grammar;
import ParseTree;
import lang::rascal::grammar::ParserGenerator;
import lang::rascal::grammar::definition::Modules;
import lang::rascal::grammar::definition::Parameters;
import lang::rascal::\syntax::Rascal;
g = grammar(#start[Module]);
s = newGenerate("_test", "Test", g);
:set profiling true
s = newGenerate("_test", "Test", g);
it takes 19s to generate the rascal parser on my machine. of which 70% is spend in unsetRec. |
Okay, rewriting that was "easy" (see: #1640). And made the parser generator 3x quicker. New profile:
|
Note, the unsetRec implementation had some problems, (due to a bug in vallang, it wouldn't go into tuples). After fixing this, I ran everything again.
(first original timings, got a new machine, so can't be compared to the old ones)
after fixing vallang bug:
So it got 3.1x quicker. but it's still in there quite a bit. 12.8% namely. Now if I inline the code for the rewriting, and avoid rebuilding new IValues, it gets a bit faster:
This reduces it to 8%. And making it 3.6x quicker at the cost of more ugly code. @jurgenvinju what do you think? switch to the fastest one? or keep the okay one with less code (and depending on a class that nobody else depends on in Vallang. |
there is only one way forward. let's merge this and factor the code later |
I've been profiling why it takes 30s+ to generate IDE's in vscode. I've noticed a pattern, it's mostly in the parsergenerator generating the parsers. But I was just curious why, so I dived in a bit.
Looking at the whole profile, 15% of the time is spend on these getVariable calls, and especially the case where it's just throwing an exception.
rascal/src/org/rascalmpl/interpreter/env/ModuleEnvironment.java
Lines 432 to 435 in fa8b7d2
Looking at the caller code:
rascal/src/org/rascalmpl/interpreter/TraversalEvaluator.java
Lines 411 to 429 in fa8b7d2
It appears to only suppose to happen when the constructors are not defined in the current scope. This leads me to wondering if there might be an import missing in the parser generator that could make this code a lot faster? The warning was removed in this commit: 330b88e
@jurgenvinju can you take a look? or explain why we can't work around it?
Also, it's all happening during import, the actual
#GrammarReference
is causing no problems. So my interpretation it's about how during imports we handle concrete syntax.The text was updated successfully, but these errors were encountered: