Benchmarks for different variable parsing techniques

[boopathi]

Compare benchmarks between #82 and #228

yarn benchmark --bench variablesWithNewJit,variablesWithOldJit,variablesWithGraphQLJS 

Results on my Mac -

size of function for variablesWithNewJit: 6727
size of function for variableCompilation variablesWithNewJit: 14847
size of function for variablesWithOldJit: 6727
size of function for variableCompilation variablesWithOldJit: 69500
size of function for variablesWithGraphQLJS: 6727
size of function for variableCompilation variablesWithGraphQLJS: undefined
Starting variablesWithNewJit
graphql-js x 148,906 ops/sec ±0.77% (234 runs sampled)
graphql-jit x 118,267 ops/sec ±0.17% (236 runs sampled)
Starting variablesWithOldJit
graphql-js x 159,093 ops/sec ±0.13% (236 runs sampled)
graphql-jit x 545,095 ops/sec ±0.11% (237 runs sampled)
Starting variablesWithGraphQLJS
graphql-js x 153,436 ops/sec ±0.14% (235 runs sampled)
graphql-jit x 237,255 ops/sec ±0.10% (235 runs sampled)

[boopathi]

Other observations -

Though the old jit (without support for cyclic input type definitions) seems to perform well for shallower input nestedness, the amount of generated code increases rapidly as we increase more levels to the nestedness.

i.e. Adding one more level of input filters in the benchmark example - L3 to L4, the length of the generated code increases from 69500 to 344204, and the bench time / performance decreases by Half - 531,561 ops/sec to 265,269 ops/sec.

While the new jit (with support for cyclic input types), we don't add this complexity because it supports cyclic input type definitions.

[boopathi]

Sending non-cyclic schema to all benchmarks, we see the following results -

nestedness at L4 - 4 levels of filters (refer variables-parsing-shallow.ts)

Starting variablesWithNewJit
graphql-jit x 148,555 ops/sec ±0.18% (235 runs sampled)
Starting variablesWithOldJit
graphql-jit x 262,649 ops/sec ±0.11% (236 runs sampled)
Starting variablesWithGraphQLJS
graphql-jit x 242,091 ops/sec ±0.11% (235 runs sampled)