C++ view AST / printAST.ql performance analysis #11221
Labels
question
Further information is requested
Comments
|
Thanks for the report. Wow, 92GB is a large database! You're right that AST building is likely to be a very local analysis. If possible, one thing to try would be to increase the amount of RAM a lot. CodeQL is a database engine and it likely tries to load the large database tables into memory . If CodeQL runs out of memory it needs to swap things out to disk which impacts performance. It would be interesting to try if a smaller database helps. There is no way to "slice" an existing database though. You can create a small database by running CodeQL with a build command that only compiles the interesting file(s). For example |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there anything the end user can do to triage extremely slow 24hr+ printAST requests? It's for a single file that has an include that relies on a lot of other compilation units. The 'db-cpp' folder is 92GB - creating a smaller slice with only this file and required compilation units wouldn't make it any faster, I think, as this query should only be accessing data related to this file to begin with? If that's a valid approach to improve this query's perf - is there an easy way to slice the existing DB or does a new build need to be run with some arg?
"Iteration 30-32" took ~4hrs each doing something similar to
DumpDeclaration::getTemplateArgumentsString. Java has an 8gb heap and pegs a single core. Is there some preferred tracing for codeql's java components I can capture?Reason I'm trying to view AST is just so that I don't have to guess at how the code flow I'm looking at is represented by codeql 😄
The text was updated successfully, but these errors were encountered: