I thought about trying to generalize the previous post to a generic GC, but it proved more difficult, so I left it out.<p>In my first post, I was mostly focused specifically on CPython, which does ref-counting with some GC to catch cycles. I was ignoring the real GC and cycles in my post; my understanding of d.clear() is that the ref counting happens and happens immediately, so <i>at best</i> it&#x27;s still O(|d|). My main point was that in the implementation you&#x27;re likely to be using, it happens at the time you run the code, and can thus change the order notation of the code (and perhaps how you expect it to perform, though you did have to construct d, which was O(|d|) at best to begin with…).<p>In a generic GC, I was thinking it <i>might</i> be fair game to ignore the GC. If GC can be done completely concurrently with the remainder of the app, and doesn&#x27;t end up effectively stealing resources (mostly, CPU, I guess) from the app, then I think I might be persuaded to call it &quot;free&quot;, or at least close to it. One might cynically call a &quot;never free; just alloc and let the OS free on process death&quot; a very naive form of garbage collection, and there, it is definitely close to free.