3 ms·
Scanning the heap looking for values that "look like pointers" in some indefinite way is a fairly unusual strategy. There are many GC'd languages -- Haskell and
by solidsnack9000 10y ago
Scanning the heap looking for values that "look like pointers" in some indefinite way is a fairly unusual strategy. There are many GC'd languages -- Haskell and O'Caml come to mind -- without this limitation. Haskell used "pointer tagging" where every value had two bits reserved at the top end and thus Ints were limited to 30 bits. The two bits were used to tell the GC what it was looking at. Later developments side-stepped this limitation but I'm not sure how.
Does ARC have an overhead relative to GC? If if it does, it at least prevents latency spikes.
- Someone 10y ago"Does ARC have an overhead relative to GC? If if it does, it at least prevents latency spikes" It doesn't prevent latency spikes. As an extreme example, create a linked list or tree with a billion nodes, and let its root go out of scope. That will call free a billion times.
- deleted 10y ago[deleted]
- solidsnack9000 10y agoDo that every request, and it will be the same each time. With GC, you can see a latency spike when every request creates such a list and they aren't freed until, due to memory pressure, many are freed all at once. Some of the requests will get stuck waiting for a linked list node and have very high latency relative to the other ones. The strength of ARC for interactive applications is its consistency.