On Sat, Feb 8, 2014 at 10:44 AM, Simon Urbanek <simon.urba...@r-project.org>wrote:
> Gábor, > > On Feb 8, 2014, at 10:19 AM, Gábor Csárdi <csardi.ga...@gmail.com> wrote: > > > Hi All, > > > > is there a caveat in redefining .Call in a package? (Apart from the > > performance hit of the extra function call.) > > > > Why don't you just do s/\.Call/myCall/g in R/* instead? That would be a > bit less dangerous in case you forget about it or need to use .Call in some > cases. > Because then I need to replace ~1000 .Call calls to myCall. Not a big deal, but it messes up version control history somewhat. Adding a .Call is much cleaner for me. > I want to execute a check every time I call back to C, and this seems to > be > > the easiest solution, instead of modifying all functions of the package. > It > > also seems to be a good way to supply the PACKAGE argument, btw. > > > > Ideally, you should not be using PACKAGE in the first place - it's mostly > for backwards compatibility. Modern packages should be using cached symbols > created by useDynLib() since they are much faster than looking up symbols > for every call which unnecessary and slow. > Might be much faster to look up, but it might be much slower to load the package if you have a lot of functions. My (uneducated) guess is that loading Matrix is very slow because of this. Never measured, though, so this is not a very strong point. The other reason is that adding a new function requires non-local modifications if you register symbols, i.e. need to update the registering code as well, which is probably elsewhere. I am auto-generating much of my R wrapper, and then my generator would need to be changed, and I am lazy. Btw. what does "much faster" mean exactly? Anybody ever measured? Best, Gabor > > Cheers, > Simon > > > > I guess this is a good solution, but I might have overlooked something. > > > > Thanks, > > Gabor > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]]
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
