-
Notifications
You must be signed in to change notification settings - Fork 57
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
1-4 second compileVariableParsing execution at runtime #244
Comments
I would definitely advise to update since there are quite a few bad bugs fixed in that version. At Zalando, all the used queries used to be compiled at start-up so compiler performance was never a major concern. However, 1s for compilation is rather excessive specially when most of it is on the variable parsing. Do you think you could share a query example that takes this amount of time? Maybe we would be able to spot something an easy win for compiler performance. Regardless, you will want to update to be ready for that fix. 😉 |
Hey thanks Rui. I really purged this one, hopefully it's somewhat useful. RE: compiled at start-up, I think that could be a good option. I'll work on updating it :) as well. I'm a bit of a GraphQL n00b, any advice is very appreciated :).
|
I was misunderstood here. I meant replacing the fields with consistent anonymized fields so we can reason about the schema. The less anonymized it is, the easier might be for us to understand. If you replacing a field named We cant make progress with your previous reply. |
A bit of a Hail Mary. I've inherited a project that uses an old version of graphql-jit, 0.5.2. The project has a complex schema and runs into 1-4 second compileQuery executions at runtime.
I've added tracing the the package. Most of the runtime is in compileVariableParsing function. It's broken out further in the provided screenshot.
Could I please get some insight into this? Possible optimizations, compilation at start time, etc.
Thank you :).
The text was updated successfully, but these errors were encountered: