On Wed, Feb 16, 2011 at 1:13 PM, Paul Gilbert <pgilb...@bank-banque-canada.ca> wrote: > (subject changed from: RE: [Rd] Avoiding name clashes: opinion on best > practice naming conventions) > > Dominick, > > Is this really true? Is there a speed advantage to defining a local function > this way, say, within another function, and then calling it within a loop > rather than the original? Do you have data on this? > > Paul
I worked on an application where a complex characteristic function was computed over and over again to compute a Fourier transform, and there was a very significant performance penalty to be paid by using myPgk::foo() compared with foo(). It was recommended on this list that I try the local assignment trick and it worked great. Unfortunately this discourages the use of programming styles that are more explicit and easier to follow for the human reader. It also complicates the problem of explicitly specifying what version of "foo()" you really mean to use. Dominick >> -----Original Message----- >> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- >> project.org] On Behalf Of Dominick Samperi >> Sent: February 16, 2011 12:44 PM > ... >> Since the resolution of myPkg::foo() occurs at runtime (via a function >> call) instead >> of at compile time (as it would in C++), this practice can introduce a >> significant >> performance hit. This can be avoided by doing something like: >> mylocalfunc <- myPkg::foo >> [tight loop that uses mylocalfunc repeatedly] >> >> Here mylocalfunc would not be exported, of course. >> >> Dominick > ... > ==================================================================================== > > La version française suit le texte anglais. > > ------------------------------------------------------------------------------------ > > This email may contain privileged and/or confidential information, and the > Bank of > Canada does not waive any related rights. Any distribution, use, or copying > of this > email or the information it contains by other than the intended recipient is > unauthorized. If you received this email in error please delete it > immediately from > your system and notify the sender promptly by email that you have done so. > > ------------------------------------------------------------------------------------ > > Le présent courriel peut contenir de l'information privilégiée ou > confidentielle. > La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute > diffusion, > utilisation ou copie de ce courriel ou des renseignements qu'il contient par > une > personne autre que le ou les destinataires désignés est interdite. Si vous > recevez > ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans > délai à > l'expéditeur un message électronique pour l'aviser que vous avez éliminé de > votre > ordinateur toute copie du courriel reçu. > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
