Fork me on GitHub
#graphql
<
2019-11-13
>
hlship19:11:09

Funny thing, I just tried running the Lacinia benchmarks where there's no ResolverResultImpl, instead resolve-as creates a ResovlerResultPromise and immediately delivers the value to it. Guess how much that affected the benchmarks?

hlship19:11:57

it's really a tiny uptick. I wonder if there's a difference in real code? And does that mean it might make sense to remove

hlship19:11:13

optimizations from lacinia concerning ResolverResultImpl?

hlship19:11:02

Ultimately, probably safest to keep the code as is, but the optimizations are relatively inconsequential, which is a surprise. I would have thought it would have been more of a double-digit percentage jump in execution time.

gklijs05:11:43

Is the code available in a specific branch? I could try to compare it to the latests released version.

hlship17:11:03

I'll push what I have. I actually went further and removed the optimizations that assume a ResolverResult (not a RRPromise).

gklijs20:11:46

I try to do several runs with the released version tonight, if it goes well (I did some changes) I can run the branch the next night.

hlship21:11:22

To what degree do you use ResolverResultPromise (e.g., async resolvers)?

gklijs21:11:51

I don't use them at all. In my case the Schema is very flat, so it wouldn't really make sense. Every GraphQL query will always be only one database query.

hlship22:11:35

Our scenario is much more complicated, with a mesh of data coming from Cassandra and half a dozen various external services. I'm working on a DataLoader library to help ensure that work is cached, shared across threads, and parallelized and batched where possible.

👍 4