Skip to content
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

Open
Dylan-G-Roberts opened this issue Apr 16, 2024 · 3 comments
Open

1-4 second compileVariableParsing execution at runtime #244

Dylan-G-Roberts opened this issue Apr 16, 2024 · 3 comments

Comments

@Dylan-G-Roberts
Copy link

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.
Screenshot 2024-04-16 at 1 01 12 PM

Could I please get some insight into this? Possible optimizations, compilation at start time, etc.

Thank you :).

@ruiaraujo
Copy link
Collaborator

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?
If it is sensitive maybe, replace all term by Foo1, Foo2, etc. 😄

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. 😉

@Dylan-G-Roberts
Copy link
Author

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 :).

{
  "foo": "FooBar",
  "bar": {
    "foo": "xxxx",
    "bar": "xxxx",
    "foo": "xxxx",
    "bar": {
      "foo": {
        "IN": ["xxxx"]
      },
      "bar": {
        "IN": ["xxxx"]
      },
      "OR": [
        {
          "foo": {
            "IN": ["xxxx"]
          },
          "bar": {
            "foo": {
              "IN": ["xxxx", "xxxx"]
            }
          },
          "foo": {
            "IN": ["xxxx", "xxxx", "xxxx", "xxxx", "xxxx", "xxxx"]
          }
        },
        {
          "bar": {
            "foo": {
              "NIN": ["xxxx", "xxxx"]
            }
          },
          "foo": {
            "IN": ["xxxx"]
          }
        }
      ]
    },
    "foo": {
      "bar": {
        "foo": "xxxx"
      }
    },
    "bar": {
      "bar": {
        "foo": {
          "NIN": ["xxxx", "xxxx"]
        }
      }
    },
    "foo": {
      "bar": {
        "foo": {
          "NIN": ["xxxx", "xxxx"]
        }
      }
    },
    "bar": "xxxx"
  },
  "foo": "foo FooBar($foo: Int!, $bar: foo, $foo: bar!, $bar: bar, $foo: Int, $bar: bar, $foo: Int!, $bar: bar, $foo: bar, $bar: bar!) {
  foo(
    foo: $foo
    bar: $bar
    foo: $foo
    bar: $bar
    foo: $foo
    foo: $foo
    bar: $bar
  ) {
    foo {
      foo
      __typename
    }
    bar {
      ...Fragment1
      __typename
    }
    foo {
      foo: bar
      bar: bar
      bar
      bar
      bar
      bar
      bar
      foo
      bar
      foo
      bar
      foo
      bar
      bar
      foo
      bar
      foo
      bar
      foo
      bar
      foo
      bar
      foo
      bar {
        foo
        __typename
      }
      foo: bar {
        ...Fragment2
        __typename
      }
      foo
      bar
      foo
      bar
      foo
      bar
      foo
      bar
      foo(
        bar: {foo: {EQ: xxxx}, bar: {EQ: xxxx}, foo: {IN: [\"xxxx\", \"xxxx\", \"xxxx\", \"xxxx\", \"xxxx\"]}, bar: {EQ: \"xxxx\"}}
      ) {
        foo {
          xxxx
          xxxx
          xxxx
          xxxx
          xxxx
          __typename
        }
        __typename
      }
      children: bar(bar: $bar) {
        foo {
          bar: bar
          foo: bar
          bar
          bar
          children: bar(bar: $foo) @include(if: $bar) {
            foo {
              bar: bar
              foo: bar
              __typename
            }
            __typename
          }
          __typename
        }
        __typename
      }
      __typename
    }
    foo
    __typename
  }
}

fragment Fragment1 on bar {
  foo {
    foo {
      foo
      __typename
    }
    bar {
      foo
      __typename
    }
    __typename
  }
  __typename
}

fragment Fragment2 on bar {
  foo {
    bar: bar
    foo
    bar
    bar 
    foo
    foo
    bar
    foo
    __typename
  }
  __typename
}
"
}

@ruiaraujo
Copy link
Collaborator

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 Customer with Foo then only Customer should be Foo

We cant make progress with your previous reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants