4 ms·
The chain variable continuously grows because each call to enqueue() creates a new promise that references the previous one. This creates an ever-growing chain
by lerp-io 1y ago
The chain variable continuously grows because each call to enqueue() creates a new promise that references the previous one. This creates an ever-growing chain of promises that never gets garbage collected.
- pinoy420 1y ago[dead]
- ath92 1y agoCouldn’t the browser garbage collect the promises (and their callbacks) that have been rejected or resolved? I.e. effectively “shift” the promises at the start of the queue that have been dealt with and will never be relevant again? At least this stackoverflow answer suggests the handlers are GC’ed: https://stackoverflow.com/questions/79448475/are-promise-handlers-cleared-from-memory-after-the-promise-is-resolved https://stackoverflow.com/questions/79448475/are-promise-han...
- jameshart 1y agoWhy does the promise returned by a promise’s then() method need to reference that promise? The original promise needs to reference the chained promise, not the other way round. As jobs complete I would expect the top of the chain to be eligible to be garbage collected.
- paulddraper 1y agoThough it seems like that, no. a = b.then(c); When `b` is resolved, it is garbage collected, even if a reference to `a` is retained. (If the runtime maintains async stack traces, that could be an issue...but that is a common issue, and the stack depth is limited.)
- deleted 1y ago[deleted]
- bapak 1y agoThat's not how promises work, there's no chain. It's no different from await job1() await job2() await job3() await job4() Except dynamic
- ameliaquining 1y agoAt least in V8, this is not the case. To prove it, start a Chromium-based browser with the command-line flag --js-flags=--expose-gc, then go to https://runjs.app/play/#aWYgKCF3aW5kb3cuZ2MpIHsKICB0aHJvdyBuZXcgRXJyb3IoJ1RoaXMgb25seSB3b3JrcyBpbiBDaHJvbWl1bSB3aXRoIC0tanMtZmxhZ3M9LS1leHBvc2UtZ2MnKTsKfQpsZXQgZmlyc3QgPSBQcm9taXNlLnJlc29sdmUoKTsKY29uc3QgcmVmID0gbmV3IFdlYWtSZWYoZmlyc3QpOwpjb25zdCBzZWNvbmQgPSBmaXJzdC50aGVuKCk7CmZpcnN0ID0gdW5kZWZpbmVkOwphd2FpdCBnYyh7dHlwZTogJ21ham9yJywgZXhlY3V0aW9uOiAnYXN5bmMnfSk7CmNvbnNvbGUubG9nKGBGaXJzdCBwcm9taXNlICR7cmVmLmRlcmVmKCkgPyAnaXMgbm90JyA6ICdpcyd9IGdhcmJhZ2UgY29sbGVjdGVkYCk7CnZvaWQgc2Vjb25kLnRoZW47ICAvLyBEb24ndCBsZXQgc2Vjb25kIGJlIGdhcmJhZ2UgY29sbGVjdGVkIHVudGlsIG5vdwo= https://runjs.app/play/#aWYgKCF3aW5kb3cuZ2MpIHsKICB0aHJvdyBu...
- bigiain 1y ago> This creates an ever-growing chain of promises that never gets garbage collected. Modern frontend development performance best practise is to allow for garbage collection only when the browser crashes.
- moralestapia 1y agoNope.
- Inviz 1y agoI wonder if people who are claiming its not the case ever tried to use promises in hardcore ways like this, chaining 10s of thousands of calls. You often hit some bullshit, i.e. Promise.race is a big cause of issues. Even if you are doing `then().then()`, something _else_ in the code base could retain the promise somehow and then your whole chain isn't GCable! For example https://github.com/rxaviers/async-pool https://github.com/rxaviers/async-pool library that implements concurrency for async iterators (and uses promise.race) subtly creates GC pressure which you dont see until you make a whole lot of calls and suddenly its slow