Skip to content

Use less memory and make parsing/validation much faster

Compare
Choose a tag to compare
@wravery wravery released this 31 Dec 06:53
54baee1

There are many miscellaneous improvements, but the core set of changes are refactoring the way that query validation and introspection work together, and how state is propagated from an object or list to the sub-fields/elements. The GraphQL parser grammar and AST generation are much more efficient and almost entirely avoid memory copies or string comparisons, except in cases where the query actually requires decoding UTF-16 escaped character sequences. The graphql::response::Value type (similar to a JSON value) is much more compact and we defer building them until we're ready to return the final result of a query, so we spend much less time and memory propagating results from sub-fields back to the final result. To support scenarios where services might not want to expose Introspection in production, schemagen now takes a new --no-introspection flag which will suppress the top-level __schema and __type fields. Compared to v3.3.0, the memory usage of the benchmark utility which parses and executes a query 100 times uses roughly 34% as much heap memory at peak, and it runs roughly 38x faster (measured with valgrind tool=massif with GCC on Linux). Many thanks to @barbieri who suggested and/or implemented most of these improvements!

I think this version is source compatible with v3.3.0, except for the definition of service::field_path. If you have any code which propagated or directly manipulated the SelectionSetParams::errorPath parameter, you may get a build break. You should consider that an opaque type and let graphqlservice take care of translating that in the error handling. Take a look at the changes in TodayMock.cpp to see what I mean, I needed to remove some redundant special handling I had implemented there to propagate the paths.

Otherwise, public methods which have been replaced are annotated with [[deprecated]] and include a message letting you know what to move to. They should still work until you are able to update your code. as long as you treat calling deprecated methods as a warning rather than an error. Those methods will be removed in the next major version update, whenever that becomes necessary.

There was a breaking change in PEGTL since the 3.1.0 release which this version of cppgraphqlgen depends on, so for now you need to either recursively clone the repo and update the PEGTL sub-module at the same, or you need to make sure that you're using a commit greater than or equal to taocpp/PEGTL@0cc3128. If you are using vcpkg, you can install both pegtl and cppgraphqlgen with the --head parameter, otherwise you should stick to the previous release until both the pegtl port and the cppgraphqlgen port have been updated. I will probably do that shortly after PEGTL releases 3.1.1 including that commit.