# More realistic timings for evaluations with large outputs [duplicate]

What timing method will take into account all (kernel and frontend) operations?

rel = CloudGet[
"https://www.wolframcloud.com/objects/bc960912-ff24-43bc-9dbd-04cf23bbcd70"];
start = Now;
Timing[Graph[rel, GraphStyle -> "Vintage", PerformanceGoal -> "Quality"]]
fin = Now;
fin - start


That is a huge discrepancy.

• It's complicated, I'm not even sure if there's a fully reliable and accurate way. Jan 11 '17 at 16:45
• The timing method you used to get the value 3.2 sec -- i.e., watching the system clock is the way to do it. Jan 11 '17 at 16:48

I am not sure if the method you show includes the rendering time.

My understanding may not be complete but at least these events should happen between Shift-Enter and the results being displayed on screen when evaluating something.

1. Evaluating something (kernel)
2. Converting the result to boxes, as in ToBoxes (kernel)
3. Sending the boxes through MathLink, possibly after compression (kernel and front end)
4. Rendering the result (front end)

I believe that AbsoluteTiming measures only (1).

t = AbsoluteTime[]
something
AbsoluteTime[] - t


should measure (1), (2) and some part of (3), but not (4).

We can measure (1) and (2) using AbsoluteTiming[ToBoxes[something];], but this won't include (3) at all.

I thought that we might be able to approximate the whole thing, (1)-(4), using AbsoluteTiming[Rasterize[something];], but this will also include sending the rasterized result back through MathLink. In practice this seem to significantly overestimate the real timing (based on comparing with a stopwatch).

Much of this answer is based on educated guesses, and may contain inaccuracies.

Note that in situations similar to what you show, step (3) will often take considerably longer than (1)-(2), and step (4) may take even longer than (1)-(3) (depending on the situation).

• Timing steps 1-3 would be sufficient for my purposes.
– M.R.
Jan 11 '17 at 20:06