Yes, but that is from contnrs. I would suggest to adapt the growth factor using one of the tables from generics.memoryexpanders.which is as wrong as it can get. It is wastes memory like there is no tomorrow after a specific size dependand on the data the capacity grow should start to getting smaller than the current item count not bigger. This is a stupid man's speed enhancer.
type FBrange = 0..45; const // Fibonacci numbers FibonacciNumbers: array[FBrange] of UInt32 = ( {0,1,1,2,3,}0,5,8,13,21,34,55,89,144,233,377,610,987, 1597,2584,4181,6765,10946,17711,28657,46368,75025, 121393,196418,317811,514229,832040,1346269, 2178309,3524578,5702887,9227465,14930352,24157817, 39088169, 63245986, 102334155, 165580141, 267914296, 433494437, 701408733, 1134903170, 1836311903, 2971215073, {! not fib number - this is memory limit} 4294967295); // unfinished code, but you get the idea. // introduce a FCapacityIndex procedure TDeque.IncreaseCapacity;inline; var i,OldEnd:SizeUInt; begin OldEnd:=FibonacciNumbers[FCapacityIndex]; inc(FCapacityIndex); SetLength(FData, FibonacciNumbers[FCapacityIndex]); if (FStart>0) then for i:=0 to FStart-1 do FData[OldEnd+i]:=FData[i]; end;
It's correct, but when we work with memory we must understand than when we use more then 1-10 MB RAM we need some slowly asymptotic(it may be Fibonacci numbers).
procedure TDeque.IncreaseCapacity;inline; var i,OldEnd:SizeUInt; begin OldEnd:=FCapacity; if(FCapacity=0) then FCapacity:=1 else FCapacity:=FCapacity*2; SetLength(FData, FCapacity); if (FStart>0) then for i:=0 to FStart-1 do FData[OldEnd+i]:=FData[i]; end;
suggestion: make first value not 1 but cInitialCapacity (const in unit).
Set it not to 1 but to 4, or better 8.
3) I think that we must make possible to use more than 4 GB*sizeof(T) memory in one TDeque => 4294967295 - isn't memory limit.It is, at least it is the memory limit of the default memorymanager for one single entity. It is not the limit of total memory.
But your tip (Fib numbers) is not yet impemented?I don't need to: Apart from small stacks and queues, I only use generic stacks and queues: there it is implemented very well.
https://github.com/graemeg/freepascal/blob/master/packages/fcl-stl/src/gdeque.pp#L141
pls apply it.
Empirically that turned out to be a good fit with varied workloads.Well, the theory behind it was added. For the general case the current status is perfectly fine. The suggestion is a nano-optimization in that case.
What about my change?The many branches in that code would make it slower than the current implementation.
What about my change?Ok, but it make some bad work with memory pages. Correct version: