Re: Re: performance // Re: Re: Why

*To*: mathgroup at smc.vnet.net*Subject*: [mg100606] Re: [mg100590] Re: [mg100559] performance // Re: [mg100548] Re: Why*From*: DrMajorBob <btreat1 at austin.rr.com>*Date*: Tue, 9 Jun 2009 03:55:14 -0400 (EDT)*References*: <h0d6s8$spq$1@smc.vnet.net> <200906070903.FAA28180@smc.vnet.net>*Reply-to*: drmajorbob at bigfoot.com

Comparing apples to apples: Clear[fn, fn1]; fn["This is my test function"][x_, y_] := x*y; fn1[x_, y_] := x*y; MapThread[ fn["This is my test function"], {Range[100000], Range[100000]}]; // Timing MapThread[fn1, {Range[100000], Range[100000]}]; // Timing {0.11964, Null} {0.108061, Null} MapThread[ fn["This is my test function"], {Range[100000], Range[100000]}]; // Timing MapThread[fn1, {Range[100000], Range[100000]}]; // Timing {0.108755, Null} {0.11406, Null} Or, as you see... no difference. I'd never use f[##]&, when f is the same thing in less keystrokes (and less time as well, apparently). Bobby On Mon, 08 Jun 2009 05:18:12 -0500, Leonid Shifrin <lshifr at gmail.com> wrote: > Hi Scot, > > The main source of overhead I see here is that myfunction[yourstring] is > first computed during evaluation, and the global rule base is searched > (hopefully with no match found:) ) for anything matching > <myfunction[yourstring]> since the head of any expression is evaluated > first. Consider this simple benchmark: > > In[1]:= Clear[fn,fn1]; > fn["This is my test function"][x_,y_]:=x*y; > fn1[x_,y_]:=x*y; > > In[2]:= MapThread[fn["This is my test > function"][##]&,{Range[100000],Range[100000]}];//Timing > > Out[2]= {0.911,Null} > > In[3]:= MapThread[fn1[##]&,{Range[100000],Range[100000]}];//Timing > > Out[3]= {0.771,Null} > > In[4]:= MapThread[fn1,{Range[100000],Range[100000]}];//Timing > > Out[4]= {0.561,Null} > > In the latter case, a small speed-up is because we can avoid an extra > parameter-passing stage [##]&, which we can not in your construction. > This > tells us about another possible source of overhead: when used in > higher-order functions such as Map, your construction can not be used by > name but needs an extra stage of constructing a pure function from it. > This > test shows about 50% slowdown, but the above test function does not > really > do much - for any realistic computation these effects will not probably > be > noticable since the main time will be spent in computing the r.h.s of the > function. > > I did not do more systematic benchmarks, but I would not expect much of a > performance hit, unless you have a single function name <myfunction> and > a > huge number of different definitions stored (which is unlikely). Of > course, > this depends on whether or not SubValues lookup is implemented as > efficiently as DownValues, which I assume is true. Again, if the body of > your <myfunction> is any computationally demanding, you probably > shouldn't > notice any overhead. Let me add that with this approach, your other > limitation is that you won't be able to set the Attributes of myfunction > such that they will affect the manipulations with var1,var2, etc. > > > Regards, > Leonid > > > > On Sun, Jun 7, 2009 at 11:05 PM, Scot T. Martin > <smartin at seas.harvard.edu>wrote: > >> On the general topic of performance, I'd be interested to know if anyone >> can comment on the following. In an effort to keep my codes as >> reasonable >> as possible, I use a lot of "sentence variables". What I mean is that >> I'll >> write: >> >> myfunction["further explanation"][var1_,var2_]:= .... >> >> I add that extra string in naming the function. This helps me immensely >> to >> remember what I'm doing and make my code accessible to me again in six >> months. I have often wondered, however, if I slow down Mathematica by >> using these long function names. >> >> Does anyone know? >> >> [For most of my applications, the limiting aspect on overall >> implementation time is my slow human CPU, so I have ample computer >> cycles >> and memory. However, there are a few applications that cause me to leave >> my computer running overnight, so I'm wondering somewhat about the >> performance of the code and if these long variable names are having an >> effect.] >> >> -- DrMajorBob at bigfoot.com

**References**:**Re: Why is recursion so slow in Mathematica?***From:*lshifr@gmail.com