3 ms·
Ref-counting GC and in particular implementation that is used in QuickJS is more deterministic I would say. In QuickJS: function Foo() { let file =
by c-smile 5y ago
Ref-counting GC and in particular implementation that is used in QuickJS is more deterministic I would say.
In QuickJS:
function Foo() {
let file = new File(...);
file.write("Happy New Year");
}
The file variable (object in it) will be destroyed immediately at the exit from the function.
Which is more suitable in case of Sciter that is embeddable [in native applications] engine.
Contrary my TIScript that I was using before had real moving/compacting GC. Objects were freed at GC cycles (in galaxy far far away from invocation).
- pjmlp 5y agoIn such basic example yes. Now try an data structure, with an unknown size of elements that can non-deterministically scale to several hundreds nodes and delete the graph root node. Which is why all high performance Ref-counting GC rely on background threads for when RC reaches zero, thus mimicking tracing GC implementations.
- nyanpasu64 5y agoIs this substantially worse than deleting a vector<unique_ptr> holding a few hundred nodes (which I don't really notice, but might be bad without me realizing)? Either way you're doing a traversal and running hundreds of destructors and deallocations, but in the refcount you need an extra deallocation and compare per node (which should be cheap compared to deallocation, if non-atomic?).
- pjmlp 5y agoAbout the same, Herb Sutter has a talk how that can even trigger stack overflow if the destructors are not written with care. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” https://youtu.be/JfmTagWcqoE https://youtu.be/JfmTagWcqoE By the way, C++/WinRT uses background threads to handle cascade deletions of COM references exactly because of this.