-
-
Notifications
You must be signed in to change notification settings - Fork 567
Performance improvements #8
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
Comments
Performance is definitely a priority. I planned to revisit executor code some day. Will take a look at your implementation when I have a chance. Feel free to submit it as pull request if you already have working implementation. The roadmap I had in mind so far is:
But I do not want to start optimizing stuff prematurely, until we get clear usage patterns and see all weaknesses of GraphQL in php in general. Obviously PHP execution model is very different from Node, so this project will diverge a lot from GraphQL JS eventually. |
Hey, I checked your implementation, but memoization you propose affects the result of query execution. When you memoize results of Test suite obviously fails hard in such approach. In other words, the work performed by library that seem useless is actually necessary. The problem is that There is also a chance that I am missing something in your idea. If you could make test suite pass with your implementation - that would help me to understand it better. |
I am a bit too unfamiliar with the graphql source to fully understand the tests and make them pass (perhaps my approach is fundamentally wrong as you say). I did the memoization under the assumption that This is a bit of a hack anyway - a different architecture which supports PHP better is by far a better approach. |
Actually As for
Call to Directives and aliases may also affect actual subfield structures. I guess the only place where we could memoize such calls is when processing homogeneous lists (lists of |
I think this happened when the field owner was not a direct sibling of the other values with the same query position:
Let's say there are 10 categories in the system. The |
Yeah. Now I see what you mean. Sorry that I didn't get your idea in the first round :) To make this optimization work library have to somehow be aware of value identity. I see you use SplObjectStorage with object hash as identity. Will recheck why exactly this optimization breaks the test suit. |
Remember that it was only one of the optimizations. The memoization of |
Hi, I'm new to the project and I like what I see already, both from the concept of GraphQL and the work done here, I'd like to say, I would love to see this happen.
However, I am working with appserver.io. Scott |
@johanobergman Merged your tweaks to code base with some modifications to make test suite pass. CollectSubFields are also memoized now, but per ObjectType to make Abstract types work. Thanks for these ideas! Also note that I reverted |
@smolinari Yeah, that would be great. But it's hard to say when I'll have enough time for these big changes, so no estimates yet. |
No problem. It is an emerging technology, so there is some time to "get it going". I sure wish Facebook would open source their server side implementation. It would be neat to see how they use HHVM (and I would assume async()) to build their Type System. Scott |
@vladar Good job! Something's not quite right though. Check out this comparision of my fork and graphql-php 0.5 https://blackfire.io/profiles/compare/f5f8ce8c-9ff2-4e9e-bbdf-b673719cbeb9/graph. I believe some methods are still called too many times. |
Here's a detailed view of graphql-php 0.5: https://blackfire.io/profiles/e67292c1-5853-451f-85d5-60e64a77c873/graph |
Try again on latest commit. Changed the way of handling complex types - now field uid also depends on exact type name. |
That works a lot better. Note that you don't have to do add I't still about 30% slower than my fork, getFieldUid is called 18000 times instead of 14000 times. |
Yes, that's probably because of Will probably revisit this once I get to N+1 problem. |
That sounds good. Thank you for the work you put into this. The performance gain has been massive! |
Closing this for now. |
I have a BIG problem with memoized results, in this example with memoizing on I get faulty result on the leaf node: Query: {
surveys(school_category:SCHOOL) {
nid
modules {
survey
}
}
} Faulty result, {
"data": {
"surveys": [
{
"nid": 85,
"modules": [
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
}
]
},
{
"nid": 707,
"modules": [
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
}
]
}
]
}
} And if I turn off memoization I get the correct result: {
"data": {
"surveys": [
{
"nid": 85,
"modules": [
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
},
{
"survey": 85
}
]
},
{
"nid": 707,
"modules": [
{
"survey": 707
},
{
"survey": 707
},
{
"survey": 707
},
{
"survey": 707
},
{
"survey": 707
},
{
"survey": 707
},
{
"survey": 707
}
]
}
]
}
} I'm not sure it's safe to memoize using the AST location and fieldname, my recommendation is to remove this performance optimization now until someone figures out how to look at the parent if that is different than previously memoized, but also that doesn't take into account if say any contextual parameter has changed. Say the user is added in some level of the graph and passed down, although atm it doesn't seem to be possible to reference the context in the resolvers to be able to add stuff (this works in the JavaScript implementation, context is passed as the third parameter). But that seems like another issue. |
hi @timbrandin can you open a new issue for this please? it will be much easier to follow thx |
Sure @mcg-web |
I've been messing around with this project a bit lately, and I've had some trouble with performance. The GraphQL executor does quite a bit of unnecessary work when it resolves fields. Since it operates recursively, larger lists have a really bad impact on performance. I have tried to fix some of the bottlenecks by memoizing objects and values that can be re-used.
I'd like to hear what you think about this approach. According to the Blackfire profiler the response was 2x faster for a large query and 1.5x faster for one I use in my app.
You can check out my fork here: https://github.com/johanobergman/graphql-php
The text was updated successfully, but these errors were encountered: