Skip to content
Prev 11179 / 12125 Next

[R-pkg-devel] Replacement for SETLENGTH

Thanks for the added explanation Iris and Tomas!

So looking at the code for xlengthgets, it does appear that I may take a memory hit for multiple large objects due to the second allocation before the old objects are possibly garbage collected.     There are about 12 such instances per function that are returned (I do use a counter for keeping track of the number of PROTECTED and to UNPROTECT for bookkeeping :-).   For memory limited machines, the alloc/copy was a problem for memory usage - and if I recall was one of the reasons in 2008 I switched to SETLENGTH, which doesn't seem to do an allocation ???  If there is going to be an absolute ban on SETLENGTH  in packages I'll probably need to address memory management differently for those cases.

I did see a note before the function def'n of xlengthgets:

/* (if it is vectorizable). We could probably be fairly */
/* clever with memory here if we wanted to. */

It would seem that memcpy would be more efficient for at least some of the types  (REALSPX, INTSPX) unless I am missing something - but any way to be more clever with VECSPX ?

best,
Merlise



Merlise Clyde (she/her/hers)
Professor of Statistical Science and Director of Graduate Studies
Duke University

________________________________________
From:?Iris Simmons <ikwsimmo at gmail.com>
Sent:?Wednesday, January 15, 2025 1:00 AM
To:?Merlise Clyde, Ph.D. <clyde at duke.edu>
Cc:?r-package-devel at r-project.org <r-package-devel at r-project.org>
Subject:?Re: [R-pkg-devel] Replacement for SETLENGTH
?
Hi Merlise!


Referring to here:

https://github.com/wch/r-source/blob/bb5a829466f77a3e1d03541747d149d65e900f2b/src/main/builtin.c#L834

It seems as though the object is only re-used if the new length is
equal to the old length.

If you use Rf_lengthgets, you will need to protect the return value.
The code you wrote that uses protect indexes looks correct, and the
reprotect is good because you no longer need the old object.

2 is the correct amount to unprotect. PROTECT and PROTECT_WITH_INDEX
(as far as I know) are the only functions that increase the size of
the protect stack, and so the only calls that need to be unprotected.
Typically, people define `int nprotect = 0;` at the start of their
functions, add `nprotect++;` after each PROTECT and PROTECT_WITH_INDEX
call, and add `UNPROTECT(nprotect);` immediately before each return or
function end. That makes it easier to keep track.

I typically use R_PreserveObject and R_ReleaseObject to protect
objects without a need to bind them somewhere in my package's
namespace. This would be that .onLoad() uses R_PreserveObject to
protect some objects, and .onUnload uses R_ReleaseObject to release
the protected objects. I probably would not use that for what you're
describing.


Regards,
??? Iris
On Tue, Jan 14, 2025 at 11:26?PM Merlise Clyde, Ph.D. <clyde at duke.edu> wrote:
Message-ID: <CY8PR05MB10034614E651AB601A74968AFC8192@CY8PR05MB10034.namprd05.prod.outlook.com>
In-Reply-To: <CADNULg9fKRf3K6Q062D7X4rUJysO=9cWA1kFEjpSv3J-Oy0bYg@mail.gmail.com>