Indeed, using profmem there is a significant advantage in memory:
> sum(mb$bytes)
[1] 261834640 #using .Fortran> sum(ma$bytes)
[1] 149221000 #using .C64
> On Dec 26, 2020, at 10:22 PM, Kasper Daniel Hansen <kasperdanielhansen
at gmail.com> wrote:
>
> Did you check memory usage? I don't know anything about Fortran, but
using .Call for C code doesn't duplicate the memory of the objects you
supply to the interface, and in some instances, that's an advantage. But
that assumes you're doing something like
> .Call("foo", xx)
> and not
> Call("foo", as.matrix(xx))
>
>
>
> On Sat, Dec 26, 2020 at 5:48 PM Koenker, Roger W <rkoenker at
illinois.edu> wrote:
> I?ve recoded a version of one of my quantile regression fitting functions
to use .C64 from dotCall64 rather than .Fortran.
> For a moderately large problem with n = 500,000 and p = 5, and solving for
1:49/50 quantiles the new version shows
> a 3% speedup, although for smaller problems it is actually slower that the
.Fortran version. So, I?m (provisionally)
> unimpressed by the claims that .Fortran has a big ?overhead? performance
penalty. Compared to the(more than) an order of
> magnitude (base 10) improvement that moving from R to fortran produces, 3%
isn?t really worth the (admittedly) minimal
> additional coding effort.