3 ms·
There is (was) a pool. It's not the alloc/free that is the problem. It's all the bookkeeping that is pure overhead compared to a simple CALL or RET instruction.
by rsc 12y ago
There is (was) a pool. It's not the alloc/free that is the problem. It's all the bookkeeping that is pure overhead compared to a simple CALL or RET instruction.
- norswap 12y agoAm I missing something or is it strange to speak about "a single CALL instruction"? It implies you'll have to execute some function, so it can't be really considered as a single instruction. If there was a pool, then the article is at least misleading on that point because it seems to imply that in loops, you repeatedly allocate and free, which would not be necessary with a pool. But yes, in the end it comes down to see whether pool/linked-list bookkeeping is better or worse to data copy + pointer bookkeeping.
- rsc 12y agoA single CALL instruction on the x86 does a very limited amount: it pushes the address of the next instruction onto the stack, and then it sets the instruction pointer to the thing that was called. What happens next is up to the function and not part of the CALL instruction. Allocate and free are perfectly reasonable terms to describe the use of a pool too.