Skip to content

parsing speed

6 messages · Federico Calboli, Duncan Murdoch, Bert Gunter +3 more

Federico Calboli
# 
Hi everyone,

I have a question on parsing speed.

I have two functions:

F1
F2

As things are now, F2 calls F1 internally:

F2 =  function(x){
if (something == 1){
y = F1(x)
}
if (something ==2){
do whatever
}
}

*Assuming there could be some difference*, is is faster to use the code
as written above or should I actually write the statements of F1 to make
the parsing faster? 

Regards,

Federico Calboli
Duncan Murdoch
#
Federico Calboli wrote:
The parsing only happens once when you define the functions, and is 
(almost always) a negligible part of total execution time.  I think 
you're really worried about execution time.  You'll probably get more 
execution time with a separate function because function calls take time.

However, my guess is that putting F1 inline won't make enough difference 
to notice.

Duncan
Bert Gunter
# 
(just my additional $.02)

... and as a general rule (subject to numerous exceptions, caveats, etc.)

1) it is programming and debugging time that most impacts "overall" program
execution time;
2) this is most strongly impacted by code readability and size (the smaller
the better);
3) both of which are enhanced by modular construction and reuseability,
which argues for avoiding inline code and using separate functions.

These days, i would argue that most of the time it is program clarity and
correctness (they are related) that is the important issue, not execution
speed.

... again, subject to exceptions and caveats, etc.

-- Bert Gunter
Genentech Non-Clinical Statistics
South San Francisco, CA
 
"The business of the statistician is to catalyze the scientific learning
process."  - George E. P. Box
Martin Maechler
# 
BertG> (just my additional $.02) ... and as a general rule
    BertG> (subject to numerous exceptions, caveats, etc.)

    BertG> 1) it is programming and debugging time that most
    BertG> impacts "overall" program execution time; 2) this is
    BertG> most strongly impacted by code readability and size
    BertG> (the smaller the better); 3) both of which are
    BertG> enhanced by modular construction and reuseability,
    BertG> which argues for avoiding inline code and using
    BertG> separate functions.

    BertG> These days, i would argue that most of the time it is
    BertG> program clarity and correctness (they are related)
    BertG> that is the important issue, not execution speed.

    BertG> ... again, subject to exceptions and caveats, etc.

Yes indeed; very good points very well put!

Just to say it again: 

 **** We strongly recommend not to "inline" your code, but rather
 **** program modularly, i.e. call small `utility' functions.

If execution time ever becomes crucial for your problem
(not often), the chances are considerable that the time spent is
 not there [[ but you have to measure! -  use Rprof() ! ]]
and if it *was* there, then you have your bottleneck in one
simple function that you could start optimizing... even a good
reason for not inlining that code..

Martin Maechler, ETH Zurich

    BertG> -- Bert Gunter Genentech Non-Clinical Statistics
    BertG> South San Francisco, CA
 
    BertG> "The business of the statistician is to catalyze the
    BertG> scientific learning process."  - George E. P. Box
 
 

    >> -----Original Message----- From:
    >> r-help-bounces at stat.math.ethz.ch
    >> [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of
    >> Duncan Murdoch Sent: Monday, May 16, 2005 3:09 PM To:
    >> f.calboli at imperial.ac.uk Cc: r-help Subject: Re: [R]
    >> parsing speed
    >> 
    >> Federico Calboli wrote: > Hi everyone,
    >> > 
    >> > I have a question on parsing speed.
    >> > 
    >> > I have two functions:
    >> > 
    >> > F1 > F2
    >> > 
    >> > As things are now, F2 calls F1 internally:
    >> > 
    >> > F2 = function(x){ > if (something == 1){ > y = F1(x) >
    >> } > if (something ==2){ > do whatever > } > }
    >> > 
    >> > *Assuming there could be some difference*, is is faster
    >> to use the code > as written above or should I actually
    >> write the statements of F1 to make > the parsing faster?
    >> 
    >> The parsing only happens once when you define the
    >> functions, and is (almost always) a negligible part of
    >> total execution time.  I think you're really worried
    >> about execution time.  You'll probably get more execution
    >> time with a separate function because function calls take
    >> time.
    >> 
    >> However, my guess is that putting F1 inline won't make
    >> enough difference to notice.
    >> 
    >> Duncan
Jan T. Kim
#
On Tue, May 17, 2005 at 09:50:20AM +0200, Martin Maechler wrote:
Generally, I fully agree -- modular coding is good, not only in R.
However, with regard to execution time, modularisation that involves
passing of large amounts of data (100 x 1000 data frames etc.) can
cause problems.

Best regards, Jan
Barry Rowlingson
#
Jan T. Kim wrote:

            

      
      
      
    

        
I've just tried a few simple examples of throwing biggish (3000x3000) 
matrices around and haven't encountered any pathological behaviour yet. 
I tried modifying the matrices within the functions, tried looping a few 
thousand times to estimate the matrix passing overhead, and in most 
cases the modular version run pretty much as fast as - or occasionally 
faster than - the inline version. There was some variability in CPU time 
taken, probably due to garbage collection.

  Does anyone have a simple example where passing large data sets causes 
a huge increase in CPU time? I think R is pretty smart with its 
parameter passing these days - anyone who thinks its still like Splus 
version 2.3 should update their brains to the 21st Century.

Baz