How one can measure the execution time (time that is spent for code to finish) of a program in Mathematica?

I understand that there are general timing functions (Timing, AbsoluteTiming, TimeUsed, etc.) that can be used for measuring CPU or wall time, but I don't know the pros/contras (and caveats) of the different methods.

  • 1
    $\begingroup$ Hi there! Look up "timing" in the help - should be some useful examples... $\endgroup$
    – cormullion
    Commented Sep 10, 2013 at 9:24
  • 1
    $\begingroup$ @Kuba Not sure it's a dupe. It is a very basic / borderline RTFM question, true, but it may be useful to have it here on SE once, for future reference. And IIRC, it has not been asked before in this most basic but direct form. I'd keep it. $\endgroup$ Commented Sep 10, 2013 at 9:32
  • 4
    $\begingroup$ But AbsoluteTiming is not enough: in a more complicated program I usually do something like $t0=AbsoluteTime[];and at the end of the (larger) program something like Print["wall clock time spent= ", AbsoluteTime[]-$0," seconds"] $\endgroup$ Commented Sep 10, 2013 at 9:37
  • 1
    $\begingroup$ Also: someone could answer, with screen shots, how to use the Workbench profiler to do timings ... $\endgroup$ Commented Sep 10, 2013 at 9:38
  • $\begingroup$ @Kuba I would agree in general, but in this particular case, the answers in that question seem a little too specialized / targeted at more advanced users. So I stand by my view that we may need some short and rather basic answer here, for this question, which is basic but important. And we can link to that one for more details, of course. $\endgroup$ Commented Sep 10, 2013 at 9:39

2 Answers 2


This question might be considered a duplicate. It is closely related to these:

However, one simple reading of this question that I do not believe is covered in the answers above is answered with this Front End option:

SetOptions[$FrontEndSession, EvaluationCompletionAction -> "ShowTiming"]

This will print the total evaluation time for each cell as it completes in the lower left window margin:

enter image description here

To make the setting persistent between sessions use $FrontEnd in place of $FrontEndSession.

Update: "ShowTiming" was already covered in Brett's answer to:

  • 1
    $\begingroup$ I found another related Q: 1722. Feel free to include it. $\endgroup$
    – Michael E2
    Commented Sep 10, 2013 at 11:37
  • $\begingroup$ @Michael I couldn't find "ShowTiming" in an answer when I searched for it. With 1722 perhaps this question is a duplicate now. I guess we have to decide if it is worth keeping open just for this list of links. What do you think? $\endgroup$
    – Mr.Wizard
    Commented Sep 10, 2013 at 11:41
  • $\begingroup$ Thats the answer of what I asked: 'SetOptions[$FrontEndSession, EvaluationCompletionAction -> "ShowTiming"]' Thanks $\endgroup$
    – sky-light
    Commented Sep 10, 2013 at 11:50
  • $\begingroup$ @barznjy You're welcome. $\endgroup$
    – Mr.Wizard
    Commented Sep 10, 2013 at 11:56
  • 2
    $\begingroup$ @Mr.Wizard I'm inclined to agree with Leonid's argument that this question serves a useful purpose, even if it's a borderline duplicate. $\endgroup$
    – Michael E2
    Commented Sep 10, 2013 at 11:58

Here's a TL;DR answer. For more details, follow Mr. Wizard's links.

  • Timing measures the computation time consumed by the kernel process, thus

    • On a 4-core machine, internally parallelized functions such as LinearSolve will show 4-times the Timing, i.e. the sum of CPU time used by each core

    • Pause doesn't use CPU time so it's not included in the Timing.

    • LibraryLink functions run in the kernel process so they're included

    • Anything that doesn't run in the kernel process, such as other processes called (Run, Import["!..."], etc.), is not included.

    • MathLink programs' run time is not included. Subkernel run times (when using the Parallel Tools) is not included

    • Rasterize and Export might not be fully measured because part of the job is done by the front end

    • Will not time the time required to send expressions to the front end and display them (e.g. render graphics)

  • AbsoluteTiming measures elapsed wall time, thus

    • If other processes are running and slow down your machine, the AbsoluteTiming that you measure will be increased. Consequently the results have more fluctuation than with Timing.

    • It can be used with computations using the parallel tools or external processes

    • Will not time the time required to send expressions to the front end and display them (e.g. render graphics)

Other things to note:

Both functions have a finite time resolution that is system dependent. On Windows XP this is around 15 ms.

Realize that a computation will typically have a part that doesn't depend on input length, and a part that does. To measure the second accurately you need to time long computations. Anything below 1 seconds is likely to be inaccurate and unusable for extrapolation to longer inputs.

One of the most common benchmarking mistakes is running too short benchmarks and letting both fluctuations and the constant part influence the result.

A good benchmark would measure how the timing depends on the length (and possibly type) of the input. For example, sorting a long list takes more time than sorting a short one. Doing this type of benchmarking will more readily reveal any benchmarking errors.

Finally, be aware that if you have a modern, SpeedStep enabled laptop CPU, frequency scaling may influence the results. I don't have a good solution for this yet, but it did bite me before. Specifically, when comparing several versions of a function, the last one I tested was penalized because by the time it ran, the CPU frequency was scaled down. This tends not to be a problem for short benchmarks. However, short benchmarks tend not to be accurate ...

  • $\begingroup$ Lots of good points in one place. +1 (I don't know why this is CW; you deserve the credit!) $\endgroup$
    – Mr.Wizard
    Commented Sep 10, 2013 at 22:29
  • $\begingroup$ +1 @Szabolcs for the clarity of your answer, I have tried to follow such guidelines, e.g. use Timing instead of AbsoluteTiming, time long computations, repeat measurements a sufficient number of times, check time resolution, etc, in a recent benchmark test on the answers of this post. $\endgroup$ Commented Aug 25, 2016 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.