# Does AbsoluteTiming slow the evaluation time?

I've started using AbsoluteTiming to discriminate between similar function constructs, but I sometimes feel like it takes substantially more time to evaluate a function using AbsoluteTiming than without.

Is this behaviour normal?

(This may qualify as a second question) Is there a way to know how much time the last evaluation took, without wrapping it in a timing function?

-
There used to be the package UtilitiesShowTime by Roman Maeder that I used whenever I wanted the timing information to be merely printed out as opposed to being part of the output. You might want to look into it, and perhaps modify the code so that it uses AbsoluteTiming[] instead of Timing[]. –  Guess who it is. Feb 14 '12 at 2:53
Could you show an example, where where using AbsoluteTiming to evaluate expr takes more time, the evaluating expr alone? –  user21 Feb 14 '12 at 8:01
An example is the case of functions built using nested loops, they tend to complete faster without being wrapped in a timing function. Non-loop equivalents do not show this behaviour. –  CHM Feb 14 '12 at 14:39

## 3 Answers

If you look in the Option Inspector, there's a setting called EvaluationCompletionAction that I keep set to "ShowTiming"

The result of this is that whenever an evaluation finishes, the amount of time it took is displayed in the status area at the bottom of the notebook

This saves me from needing to remember to wrap inputs in Timing or AbsoluteTiming.

One thing to note is that the time shown includes the conversion of the kernel output to boxes as well as the MathLink transmission time. I don't think it includes any time used by the frontend to draw the result to screen.

The downside is that there's no history.

-
Aaah, this is interesting. I'm sure there's a way to save the time in a list. Just have to figure it out. Thanks! –  CHM Feb 14 '12 at 14:48

When I don't want to use a wrapper to see how much time is used, I use AbsoluteTime[]:

timming=AbsoluteTime[];
calculations...
timming=timming-AbsoluteTime[];


Something I like about AbsoluteTime[] is that if necessary it can be converted to "normal" time, so you can track your work.

-

I don't think there is a noticable difference.

Considering what an easy function AbsoluteTiming is, you might as well build your own version and see how it compares (remember to start a fresh kernel before evaluating):

SetAttributes[myAbsoluteTiming, HoldAll];
myAbsoluteTiming[calculation_] := Module[{startTime, deltaTime, result},
startTime = SessionTime[];
result = calculation;
deltaTime = SessionTime[] - startTime;
{deltaTime, result}
]
myAbsoluteTiming@Prime[10^11]

{7.042020, 2760727302517}


Let's compare that to the built-in function:

AbsoluteTiming@Prime[10^11]

{7.058939, 2760727302517}


Considering how little memory and computation time is used by myAbsoluteTiming (just by looking at its code), I don't think there is any reason to assume that myAbsoluteTiming slows you down, and the intenal implementation is most likely even faster. (If you're using it a million of times in a matter of seconds, then maybe you'll notice an impact on performance, but that's hardly a useful application of the function.)

"Well, maybe SessionTime is slow ..." - nope:

AbsoluteTiming@Do[SessionTime[], {10^6}]

{3.665901, Null}


Concerning your follow-up question, what you want is basically the content of the Module in the code for myAbsoluteTiming given above: determine SessionTime before and afterwards, calculate difference.

-
It's funny how in this particular example your function is faster than the built-in. :P –  CHM Feb 14 '12 at 14:50