Update (on the same 1-tuple view):
// SLOW bn = COLcopy(l, l->ttype, TRUE, TRANSIENT);
// SLOW bn = COLnew(0, l->ttype, BATcount(l), TRANSIENT); BATappend(bn,l,FALSE);
// FAST bn = COLnew(0, l->ttype, BATcount(l), TRANSIENT); BATloop(l, p, q) { bunfastapp(bn, BUNtail(li, p)); }
// FAST bn = COLnew(0, l->ttype, BATcount(l), TRANSIENT); BATloop(l, p, q) { BUNappend(bn, BUNtail(li, p), FALSE); }
It gets slow also when using BATappend. It seems again related to trying to be smart with a bulk copy of the heap.
On 16 March 2017 at 13:03, Sjoerd Mullender sjoerd@acm.org wrote:
On 16/03/17 12:23, Roberto Cornacchia wrote:
I'm seeing a strange behaviour with COLcopy(). (Dec2016, optimized, non-devel compilation)
In short, it seems to take almost half second to copy a 1-tuple string (view) bat.
Inspected with gdb, I see that the copy falls in "(3) we can copy the heaps (memcopy, or even VM page sharing)", with the following values:
cnt = 1 bunstocopy = BUN_NONE isVIEW(b) = TRUE VIEWtparent(b) = 0 b->T.heap.size = 1024 b->T.vheap.size = 1094320128
The actual tail and heap copy then takes place:
heapcopy(bn, "tail", &bthp, &b->theap) heapcopy(bn, "theap", &thp, b->tvheap)
Does this mean that a heap of almost 1GB has been copied for a 1-tuple
view?
Looks like it. ;-)
A little higheer in the code is a comment "reduced slice view". That seems to be to not copy the whole heap when only a small (less than half) part of the "tail" heap is actually needed. A similar check should probably be made for the tvheap.
Roberto
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-- Sjoerd Mullender
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list