The code sets up a pool, and then calls getOutputAmount 4 times, measuring the time from execution to the promise resolving. When all 4 have finished, it will then log the total time taken. Here's an example result:
o4 232
o2 297
o3 337
o1 347
Total time 348
o1 / o2 / o3 / o4 is each getOutputAmount call and Total time is... y'know, total time. All in MS
I know getOutputAmount is async for data retrieval reasons, like web calls etc. But all data used in my example is all local, no network requests or anything. So execution should be pretty synchronous.
But as we can see, total time is about the same time as the longest getOutputAmount call and not the sum of all calls, indicating there's some sort of delay happening somewhere.
NoUJoe
commented
1 year ago
Been testing Pool. Long story short, I discovered something odd when timing the performance of some functions.
I've made a gist for replication:
https://gist.github.com/NoUJoe/d57b3d478767dd409bab7e8f6aff44e0.js
The code sets up a pool, and then calls getOutputAmount 4 times, measuring the time from execution to the promise resolving. When all 4 have finished, it will then log the total time taken. Here's an example result:
o4 232 o2 297 o3 337 o1 347 Total time 348
o1 / o2 / o3 / o4 is each getOutputAmount call and Total time is... y'know, total time. All in MS
I know getOutputAmount is async for data retrieval reasons, like web calls etc. But all data used in my example is all local, no network requests or anything. So execution should be pretty synchronous.
But as we can see, total time is about the same time as the longest getOutputAmount call and not the sum of all calls, indicating there's some sort of delay happening somewhere.