-
Notifications
You must be signed in to change notification settings - Fork 51
Merge cached validation #133
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
Merged
Merged
Changes from all commits
Commits
Show all changes
19 commits
Select commit
Hold shift + click to select a range
f7b7ed8
Add a benchmark based on sample
wravery 3956732
schemagen allow introspection to be disabled
barbieri 91249d5
Skip validation for now without Introspection
wravery 4bf0b78
Generate a compact schema
wravery 88ed5c6
Remove uneeded forward declares
wravery 8eaf8c2
Make a weak singleton GetSchema function
wravery 3dd30f0
Not passing tests yet, but refactor is done
wravery bf1221c
Fixed the rest of the tests
wravery f9d584c
Split out graphqlservice_nointrospection
wravery 5fb0f42
Export schema accessors for introspection in separate DLL
wravery b8fdb0f
Cherry-pick new unit test to pin behavior
barbieri 5e1a4ff
Optimize response::Value to avoid memory copies
wravery 64f2dae
Merge branch 'merge-cached-validation' of https://github.com/wravery/…
wravery 2586c89
Fix order of template specialization defintions
wravery 9184e91
optimize Request::findOperationDefinition()
wravery b1b734b
Only call validate from findOperationDefinition
wravery fde76cb
Store results in ResolverResult until final return
wravery d0c8ed4
Skip descriptions for --no-introspection
wravery b88ba8e
Map directly to types instead of names
wravery File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any reason to keep using map instead of unordered_map?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm acutally thinking of replacing them all with sorted vectors: https://youtu.be/fHNmRkzxHWs?t=2818
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The key with vectors is to avoid reallocating on append by reserving or resizing to the exact size you need, and not inserting/removing other than at the end. But for most of these objects that should be doable, they're static for the lifetime of the service.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you're moving to sorted and looking into static... why not target
array? There is a generator tool to help that, then we can try to get more stuff into.ro-datasection of the binaries.There is no need to get the
vectorhelpers.The binary search is not as fast as an unordered map, but I think it doesn't matter much for these use cases. If so we can look into integrating https://www.gnu.org/software/gperf/manual/gperf.html or an equivalent later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of them still have a size which varies, so it couldn't be built into the
graphqlservicelibrary directly. The generated code would need to pass a span/range intographqlserviceto get dynamic sizing backed bystd::arraywith a fixed size in the generated code.C++20 adds span/range, so that would make sense whenever cppgraphqlgen moves to that language version (I'm tentatively planning on doing that for v4.0). There's also the
gsl(C++ Core Guideline Support Library) which adds lookalike definitions ofstd::span<>, so that's another option that makes C++20 adoption easier down the road. But I'm reluctant to add another build dependency unless/until it's absolutely worth it.I'm not so worried about the quality of the
std::hashimplementation forstd::string_view, and integers/pointers can just hash to their own value.The multiple levels of indirection and poor data locality (cache misses) in
std::unordered_mapoverwhelm the savings on lookup compared to a binary search, until you get to a very large number of items. Anecdotal benchmarks I've heard say you need at least 100 entries to makestd::unordered_mapbreak even, but really we should do some of our own benchmarking/profiling.You mentioned you are dealing with large numbers of fields per object, so maybe you're more likely to hit that break even point than I expected. If you want to try comparing them for your scenario, take a look at fa772a1 where I already did this for the
ResolverMapgenerated forObject. If you locally change where it declares theResolverMaptype as astd::vector<std::pair<>>back tostd::unordered_mapand change the lookup inSelectionVisitor::visitFieldback to a call tofind, you can see if/what difference it makes.