Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

I want to know how much wall-time it takes to display a Graphics

For example this one:

ballGrid[n_] := Module[{lines},
  lines = Line[Flatten[Table[{
       {{i, j, 0}, {i, j, 1}},
       {{i, 0, j}, {i, 1, j}},
       {{0, i, j}, {1, i, j}}},
      {i, 0, 1, 1/n}, {j, 0, 1, 1/n}], 2]];
  Graphics3D[{Sphere[Tuples[Range[0, 1, 1/n], 3], 1/(10 n)], lines}, 
   Boxed -> False]]

First of all note that running ballGrid[50] and ballGrid[50]; takes significantly different wall time to run

Just using AbsoluteTiming does not give accurate representation (I assume it only measures kernel time):

In[]:= AbsoluteTiming[ballGrid[50];]
In[]:= AbsoluteTiming[ballGrid[50]]
Out[]:= {0.082963,Null}
Out[]:= {0.029378,<<Graphics>>}

I answered my own question, but I'd like to see other solutions too, and know why/if the Print workaround can be trusted

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

From past experimentation (not all of which I remember) here are several things that contribute to the time it takes to display graphics, including:

  • converting the Graphics expression to boxes (in the kernel)

  • compressing the result if it's very large (if you examine large graphics cells, you'll notice that they're compressed)

  • transferring the (possibly compressed) box expression to the Front End through MathLink

  • rendering the graphics

I played with these a little bit in the past, trying to figure out what contributes the most to the timing. Unfortunately I don't remember all the details (and I won't have time to do all the tests again now), but I do know that: 1. converting to boxes might take longer than the rendering itself in some cases 2. compression may take measurable time too.

If you want to measure the full time needed to display a Graphics, then I recommend something like

s = AbsoluteTime[];

ballGrid[30]

AbsoluteTime[] - s

In order or this to give correct results, each command must be in a separate cell.

This gives me 4.9 seconds, which is about the same time I measure with my watch.

The following should be a good approximation to the total display time too, but it'll usually take a little longer to evaluate (5.1 seconds here):

ExportString[ballGrid[30], "BMP"]; // AbsoluteTiming

This will measure box generation only (1.2 seconds):

AbsoluteTiming[ToBoxes[ballGrid[30]];]

You can add compression on top of that (1.8 seconds), AbsoluteTiming[Compress@ToBoxes[ballGrid[30]];], but I'm not sure that the same compression method implemented in Compress is used when sending the data to the FE.

Your method (AbsoluteTiming[Print@ballGrid[30]]) should include at least box generation and compression, and possibly MathLink transfer too (just a guess, I'm not sure about this last one). It gives 2.0 seconds on my machine, but I can measure 5 seconds with a watch before I actually see the graphics.

I hope this answer will help you in digging deeper into what happens exactly when graphics are displayed and how to time the process correctly ... I simply wanted to point out that doing this is not quite as straightforward as it might seem at first.

share|improve this answer
1  
Please see this too. Sometimes you can convert the Graphics to boxes yourself, speeding up the process considerably. –  Szabolcs Nov 15 '12 at 17:00
add comment

I typically execute t=AbsoluteTime[] immediately before execution of the graphics command (in the same cell, even) and then execute AbsoluteTime[]-t in the cell immediately after. It's important that you select and enter both Input cells simultaneously - as the cells are selected in the image below.

enter image description here

share|improve this answer
    
That gave me 2s extra compared to the Print workaround, and that agrees with true time. How come they have to be on different input cells? Does that force Mathematica to render the output before giving the next input to the kernel? –  ssch Nov 15 '12 at 16:58
    
@ssch I believe that's essentially correct. Rendering is done in the front end. Once a Graphics expression is sent to the front end, the kernel can get to work on input in the current cell, but not the next cell. –  Mark McClure Nov 15 '12 at 17:13
add comment

One workaround is to use Print

In[]:= AbsoluteTiming[Print[ballGrid[50]];]
<<Graphics>>
Out[]:= {14.438180, Null}
share|improve this answer
1  
I think this will time formatting the graphics expression (converting to boxes), but it will not time rendering. Depending on what sort of graphics you are displaying, both operations might take a significant time. –  Szabolcs Nov 15 '12 at 16:40
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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