MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

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

Comparing apples to apples:

Clear[fn, fn1];
fn["This is my test function"][x_, y_] := x*y;
fn1[x_, y_] := x*y;
    fn["This is my test function"], {Range[100000],
     Range[100000]}]; // Timing
MapThread[fn1, {Range[100000], Range[100000]}]; // Timing

{0.11964, Null}

{0.108061, Null}

    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).


On Mon, 08 Jun 2009 05:18:12 -0500, Leonid Shifrin <lshifr at>  

> 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>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

  • Prev by Date: Re: Multi-level Menu (ActionMenu)
  • Next by Date: Documentation Methods and Efficiencies
  • Previous by thread: Re: performance // Re: Re: Why is recursion so
  • Next by thread: Documentation Methods and Efficiencies