[Guido]
> Just in case nobody had thought of it before, couldn't the realloc()
> call be avoided when roundupsize(oldsize) == roundupsize(newsize)???
I had thought of it before, but never acted on it <wink>. roundupsize() has
gotten more expensive over the years too, and it may vary across boxes
whether it's cheaper to call that a second time than it is to make the
system realloc deduce that nothing needs to be done. roundupsize() is
certainly cheaper than Microsoft's realloc() in the do-nothing case.
Note that there's an endcase glitch here when oldsize==0 and newsize==1.
roundupsize() returns 8 for both, but it doesn't follow that ob_item isn't
NULL. realloc(p, n) special-cases the snot out of p==NULL to avoid crashing
then.
Note in passing that roundupsize() is expensive *because* lists don't
remember the amount of overallocated space too: roundupsize() has to
arrange to deliver the same result for many consecutive inputs, to prevent
asking the platform for non-trivial reallocs() ("trivial realloc" ==
"do-nothing realloc" == realloc(p, n) called with fixed p and n multiple
successive times). If we knew the point at which the "excess" slots were
exhausted, then, e.g., doing realloc(oldsize + (oldsize >> 4)) at that point
would give similar behavior with a much cheaper "new size" function (if we
only computed a new size when a new size was actually needed, the "new size"
function wouldn't have to arrange to remain constant over (eventually)
unboundedly long stretches of consecutive inputs).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4