- Run
useForLoop
independently, and observe it takes about 7 seconds to complete - Run
entrypoint
which calls useForLoop three times, asynchronously - Observe that the second run takes at least three times as long as the first run to complete
- Repeat the process above but in a browser, and observe the expected behaviour
Conclusion: Even though the documentation indicates that you can define async functions, and that you can make Promises, it ain't actually async.
Even more proof is in the fact in observing what happens when you run in the browser. It executes entrypoint()
immediately and "finishes" (although the calculations are still being made) and eventually outputs. But for the V8 engine, it indicates to the user that it is running and doesn't immediately return to the user.
- Why is
setTimeout
undefined butPromises
andAsyncFunction
work as expected (minus the actual async) - Will Google have another implementation where they do work?
Please see this gist to see the only way to do async on AppsScripts platform. (Note: It now requires you to create your own GCP project and link new project to that manually.)
OK I did some more testing and now coming to agree with you when you mix in App Script services. Take the following example:
The Promise.All is being processed serially when you add an Apps Script service.. It's like there is a separate stack for App Script service calls. When ever a call to a service happens it get added to the stack and that is processed serially. So Promise.all just adds the call to the stack faster then adding is serially. No real time savings. It only makes sense if your Promise.all is doing something computationally expensive in addition to the Apps Script service call which if you look at my last comment is much faster.