Avoid processing same structures over and over #33
Assignees
Labels
Comments
KitsuneRal
added a commit
that referenced
this issue
Jun 1, 2020
Closes #33. This massively improves GTAD execution speed with no repetitive parsing+analyzing+printing of the same files included from several places. Now every file this GTAD invocation has ever seen is analysed exactly once, and the code for each is generated no more than once (files for empty/trivial models are not emitted, as before). To accomplish this: * Analyzer now owns Models (instead of Translator) and keeps a cache of models already created. * To skip waiting for the generated file name to be returned from Printer::print(), file names are no more generated from Mustache; instead, extensions to file names are stored in gtad.yaml, so that Translator could trivially generate the file names by concatenating the original API file name base (sans extension) and the extension(s) taken from the configuration. * Analyzer::loadDependency() and Analyzer::fillDataModel() are introduced to process dependencies included via $ref nodes in the API instead of Translator::processFile(). * With no more need to be in Translator, the processFile() code has been moved to main.cpp; the whole sequence in main.cpp has been then rewritten to first analyze all models and only then iterate over the cache accumulated by Analyzer, calling Printer::print() on each non-empty, non-trivial model. * To track nested calls to loadDependency(), Analyzer stores the stack of models and their respective directories (the latter - to correctly resolve relative $ref paths). This allows to keep the only Analyzer instance for the whole set of API files instead of creating a new one for each inclusion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As of now, if the same data structure (
$refed, e.g.) is encountered several times in the API description it gets parsed, and has code generated, every time anew. So far GTAD generates the same code for externally ($ref) defined schemas; however, if In/Out direction is applied to those schemas, things may get broken (imagine the same structure$refed both from request and from response).The proper way to fix it would probably be to accumulate all data models in memory before dumping them all to
Printer. This will enable extending those models as they get encountered in the API description (e.g. add Out to already known In direction).The text was updated successfully, but these errors were encountered: