Skip to content

[WIP] Execution planning phase #56

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

Merged
merged 7 commits into from
Jul 19, 2016
Merged

Conversation

Horusiath
Copy link
Contributor

@Horusiath Horusiath commented Jul 13, 2016

DO NOT MERGE: work in progress

/cc #53

This PR introduces a planning phase - a intermediate step, when given a query to execute and a schema, we create an intermediate representation (so called ExecutionPlan) for that query. Execution plan solves things like:

  • Ability to traverse through execution plan in order to get an overall info about executed query - useful in things like generating SQL queries only for queried fields.
  • Unwrapping fragments (which are purely query language constructs and have no reflection on the actual type system). This way we can present data in a way it actually should be executed.
  • Linking to actual field definitions - making a direct execution of resolve functions quite easy. It also gives a potentially better validation support as we can now clearly jump between AST components defined in GraphQL query and schema type definitions.
  • In the future: in case of publish/subscriber scenarios, execution plans could be potentially cached for each subscriber, reducing a cost of resolving data to be published.

At the moment execution plan is not yet integrated into execution engine, but it has a dedicated (passing) test suite already.

@Horusiath
Copy link
Contributor Author

Performance benchmark results for the latest (working but not optimized) version:

Latest DEV

BenchmarkDotNet=v0.9.7.0
OS=Microsoft Windows NT 6.2.9200.0
Processor=Intel(R) Core(TM) i5-6300HQ CPU 2.30GHz, ProcessorCount=4
Frequency=2249999 ticks, Resolution=444.4446 ns, Timer=TSC
HostCLR=MS.NET 4.0.30319.42000, Arch=32-bit RELEASE
JitModules=clrjit-v4.6.1080.0

Type=SimpleExecutionBenchmark  Mode=Throughput  
Method Median StdDev Mean Min Max Op/s Gen 0 Gen 1 Gen 2 Bytes Allocated/Op
BenchmarkSimpleQueryUnparsed 254.6104 us 8.9155 us 256.7901 us 241.3560 us 271.8625 us 3894.23 116,17 - - 9 118,41
BenchmarkSimpleQueryParsed 219.1843 us 5.1253 us 220.1162 us 210.7201 us 229.2262 us 4543.06 77,25 - - 7 025,03
BenchmarkFlatQueryUnparsed 266.6233 us 9.1524 us 268.0733 us 250.2482 us 286.5097 us 3730.32 116,00 - - 9 089,21
BenchmarkFlatQueryParsed 221.1129 us 5.8084 us 221.0879 us 214.1268 us 230.7783 us 4523.09 72,62 - - 6 624,44
BenchmarkNestedQueryUnparsed 329.1764 us 6.8951 us 330.0369 us 309.8747 us 338.0075 us 3029.96 224,57 - - 17 231,50
BenchmarkNestedQueryParsed 219.7228 us 7.0313 us 221.0564 us 209.3273 us 240.2336 us 4523.73 63,95 - - 5 854,33

This PR

BenchmarkDotNet=v0.9.7.0
OS=Microsoft Windows NT 6.2.9200.0
Processor=Intel(R) Core(TM) i5-6300HQ CPU 2.30GHz, ProcessorCount=4
Frequency=2249999 ticks, Resolution=444.4446 ns, Timer=TSC
HostCLR=MS.NET 4.0.30319.42000, Arch=32-bit RELEASE
JitModules=clrjit-v4.6.1080.0

Type=SimpleExecutionBenchmark  Mode=Throughput  
Method Median StdDev Mean Min Max Op/s Gen 0 Gen 1 Gen 2 Bytes Allocated/Op
BenchmarkSimpleQueryUnparsed 246.5309 us 8.0736 us 246.6893 us 234.7599 us 265.6394 us 4053.68 135,00 - - 10 515,05
BenchmarkSimpleQueryParsed 214.0094 us 4.2676 us 212.9528 us 205.4597 us 219.0209 us 4695.88 106,00 - - 9 302,80
BenchmarkFlatQueryUnparsed 262.7956 us 11.9310 us 265.4225 us 245.9617 us 287.3243 us 3767.58 171,99 - - 13 402,87
BenchmarkFlatQueryParsed 212.6905 us 4.8144 us 213.0066 us 204.3534 us 224.8488 us 4694.69 117,53 - - 9 134,24
BenchmarkNestedQueryUnparsed 354.9459 us 12.0417 us 353.2957 us 327.1002 us 372.0679 us 2830.49 309,39 - - 23 575,72
BenchmarkNestedQueryParsed 226.8907 us 4.8996 us 226.9953 us 220.6668 us 239.5097 us 4405.38 147,57 - - 11 151,07

In general a speed remains unchanged - it's slightly faster for simple queries, and a little slower for deep complex ones. There is visible change in number of allocations performed and a little higher memory usage - which is quite obvious as we introduced an intermediate representation and an additional step between parsing and execution phases.

@Horusiath Horusiath merged commit c1a540d into fsprojects:dev Jul 19, 2016
Horusiath added a commit to Horusiath/FSharp.Data.GraphQL that referenced this pull request Jul 19, 2016
Horusiath added a commit that referenced this pull request Jul 19, 2016
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

Successfully merging this pull request may close these issues.

1 participant