Array append performance
Lionello Lunesu
lionello at lunesu.remove.com
Sun Aug 24 19:49:07 PDT 2008
"bearophile" <bearophileHUGS at lycos.com> wrote in message
news:g8ni6o$12k2$1 at digitalmars.com...
> Note2: In the D code the final deallocation of the array is fast enough,
> and its allocation is fast too (you can see this timing just the for loop
> in the middle of the program). The really slow part seems to be the loop
> itself.
If the others are right, D's probably using std.gc.capacity to constantly
check the capacity of the array. Interestingly, the Phobos GC caches the
pointer/size in a call to "capacity", so that requesting the capacity of the
same pointer immediately returns its capacity without any look-up. See
function sizeOfNoSync, in internal/gc/gcx.d. Additionally, if there are no
other threads, the GC lock is not taken, so capacity() should be O(1).
It would be interesting to check whether the cached pointer/size in the GC
is actually being used. If it is not, it would result in a call to
findSize() which in turn calls findPool(). findPool() is O(n), n = number of
pools. The pooltable is already sorted, so this can be made O(log n).
findSize() then does a linear search to check the size of the alloced block,
which is O(m), m = size of block.
Result: getting the capacity of a pointer is O(m+n). There's a lot of room
for improvement right there.
L.
More information about the Digitalmars-d
mailing list