dataloader
dataloader copied to clipboard
graphql
Is there a performance benchmark?
I use GraphQL and Dataloader in production. I have experienced some performance issues with Dataloader because our code might create 1,000+ promises per second by using Dataloader.
Not necessarily a performance issue with Dataloader itself, but I would like to understand more performance metrics of Dataloader itself in order to optimize my code.
If there isn't one already, are current tests a good approximation of the performance?
I'm curious about this as well, just as a gauge of comparative performance. In Rust this could be done in as little as 8 microseconds, but I imagine in JS this is thousands of times slower.
DataLoaders are currently our main memory hog, indeed creating 1000s of Promises, JS context objects or array literals as we have a few levels of GraphQL resolvers, resolving up a few tens of thousands of objects. At this level, V8 garbage collection starts to become a bit of problem.
I traced some of the problems to the .load() function, creating a new Promise and such for every call. I am currently investingating if I could create an alternative that could somehow reuse the same Promise accross multiple load() calls.
DataLoaders are currently our main memory hog, indeed creating 1000s of Promises, JS context objects or array literals as we have a few levels of GraphQL resolvers, resolving up a few tens of thousands of objects. At this level, V8 garbage collection starts to become a bit of problem.
I traced some of the problems to the .load() function, creating a new Promise and such for every call. I am currently investingating if I could create an alternative that could somehow reuse the same Promise accross multiple load() calls.
Any findings?
@nicoabie Unfortunately not yet - we've been too busy with other things. We kicked the can forward by compiling node.js with pointer compression. That reduced our memory load enough that this is not currently our biggest challenge.
This morning I had a moment to think about this, yet still nothing concrete yet :(
I was wondering - perhaps async generators would work here. The problems raised at graphql-js repo seem a bit similar: https://github.com/graphql/graphql-js/issues/2262
As far as I could understand, their problem is with blocking and here is with a lot of memory being used creating new promises. I don't see how the async generators would prevent creating the large amount of promises. 😕
I must say I'm not expert on async generators either - I don't know what the underlying mechanism is, e.g. does it create context objects in the same way as Promises do. At least in my case the biggest problem is not the memory used, but the fact that every object allocated from heap needs to be garbage collected.