-
Notifications
You must be signed in to change notification settings - Fork 2
Resolve data race issues with concurrent field evaluation & added benchmark tests #22
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
base: sogko/experiment-parallel-resolve
Are you sure you want to change the base?
Conversation
- Protect shared fields across routines for `Object`, `Enum` and `Schema` - Discovered through `go test ./... -race` - Standardise mutex field names *Mutex
… from here for perf-related PRs. - simple hello world equivalent - with a list - deeper query with list - query with many root fields and list in each of them - deeper query with many root fields and lists To really bring out probable issues with query perf, a latency is introduced to the data retrieval (previously it was just in-memory data fetch) When testing against branch before PR #20 and #21, this really highlighted the problem with evaluating list fields. In the future, more benchmarks for queries with fragments probably would be useful.
/cc @andreas @chris-ramon @Mleonard87 Initial benchmark tests for basic queries; something we can work upon from here for perf-related PRs. Current benchmark suite:
Added simulate latency for data retrieval When testing against branch before PR #20 and #21, this really highlighted the problem with evaluating list fields. (Using Other possible queries to benchmark Preliminary benchmark results notes:
resolve-data-race #22
experiment-parallel, after #20/#21
experiment-parallel, before #20/#21
0.5.0 (before experiment-parallel)
|
Great work and interesting results! I'll try dive into the changes when time permits. |
If you guys were underwhelmed by the benchmark results (I kinda was lol), a preliminary benchmark after including changeset from graphql-go#137 into this PR, yielded promising results. (That PR by @Matthias247 optimised the resolve-data-race #22 + graphql-go#137
Compared to Edit: Google docs table of above results Cheers! /cc @Matthias247 |
Fix further typo. Coding way early in the morning after a late night out is not a good idea - Tim Burton
Follow up to PR #20 and #21
Resolve data race issues and added initial benchmark tests
Object
,Enum
andSchema
go test ./... -race
Enum. getValueLookup()
andSchema.IsPossibleType()
/cc @andreas @chris-ramon @Mleonard87