1-4 second compileVariableParsing execution at runtime about graphql-jit

[ruiaraujo]

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]

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]

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.