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