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