MathGroup Archive 2009

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

Search the Archive

Re: performance // Re: Re: Why is recursion so

  • To: mathgroup at smc.vnet.net
  • Subject: [mg100590] Re: [mg100559] performance // Re: [mg100548] Re: Why is recursion so
  • From: Leonid Shifrin <lshifr at gmail.com>
  • Date: Mon, 8 Jun 2009 06:18:12 -0400 (EDT)
  • References: <h0d6s8$spq$1@smc.vnet.net> <200906070903.FAA28180@smc.vnet.net>

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


  • Prev by Date: Re: Integrate Bug
  • Next by Date: Re: Mathematica bug??
  • Previous by thread: performance // Re: Re: Why is recursion so slow in
  • Next by thread: Re: Re: performance // Re: Re: Why