Services & ResourcesWolfram ForumsMathGroup Archive

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

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