Version 6 graphics can be painfully slow
Szabolcs Horvát
In some cases, version 6 graphics can be painfully slow. Consider this
example:
data = Table[{Random[], Random[]}, {100000}];
Graphics[{PointSize[0.002], Point /@ data}, AspectRatio -> Automatic] //
Show
This used to work fine in version 5.2, but it takes forever to complete
in version 6.0.1. I have a dataset with about 250 000 points that I
would like to plot, so this problem is really annoying ...
The strange thing is that as soon as the graphic appears, resizing is
fast and works fine (especially with antialiasing disabled). So it is
not the /drawing/ itself that takes so long.
I really hope that these problems will be fixed in 6.1, but until then,
does anyone have a suggestion for speeding this up?
(At the moment I temporarily switch back to << Version5`Graphics`)
Szabolcs
Albert Retey
This is very fast on my computer:
data = Table[{Random[], Random[]}, {100000}];
Graphics[{PointSize[0.002], Point[data]}, AspectRatio -> Automatic]
note that Point now accepts a list of coordinates and generates a point
for each of them. This is presumably there because for whatever reason
the "old" way is too slow. My speculation is that with the new graphics
engine with the old syntax they need to create a point object for each
of the 100000 points where in the old engine only a string append to the
postscript code was necessary.
hth,
albert
Carl Woll
>In some cases, version 6 graphics can be painfully slow. Consider this
>example:
>
>data = Table[{Random[], Random[]}, {100000}];
>Graphics[{PointSize[0.002], Point /@ data}, AspectRatio -> Automatic] //
>Show
>
>This used to work fine in version 5.2, but it takes forever to complete
>in version 6.0.1. I have a dataset with about 250 000 points that I
>would like to plot, so this problem is really annoying ...
>
>
Use Point[data] instead of Point/@data, and the speed will improve
greatly (around 90 times on my machine).
I don't know all the details here, but basically, graphics work by
having the kernel send information to the front end that the front end
then renders. By using Point[data], you are sending a much smaller
amount of data to the front end since data is packed, but Point/@data is
not. Also, if the front end gets a list of Point objects, it must do
additional processing that is avoided if you instead give a Point object
containing a list of points.
So, the rule of thumb to follow is to try to always use a single Point,
Line, Polygon, etc. primitive instead of a list of such primitives.
Carl Woll
Wolfram Research
nigol
on my system and Mathematica 6.0.1 your original example takes 54.2s
to complete:
data = Table[{Random[], Random[]}, {100000}];
Graphics[{PointSize[0.002], Point /@ data}, AspectRatio -> Automatic]
The following equivalent statement (not available in Mathematica 5.2)
takes 0.173s:
data = Table[{Random[], Random[]}, {100000}];
Graphics[{PointSize[0.002], Point[data]}, AspectRatio -> Automatic]
The version 5.2 graphics takes 1.58s to complete:
<< Version5`Graphics`
data = Table[{Random[], Random[]}, {100000}];
Graphics[{PointSize[0.002], Point /@ data}, AspectRatio ->
Automatic] // Show
In[69]:= $Version
Out[69]= "6.0 for Microsoft Windows (32-bit) (June 19, 2007)"
Dario
Murray Eisenberg
$Version
6.0 for Microsoft Windows (32-bit) (June 19, 2007)
Timing[data = Table[{RandomReal[], RandomReal[]}, {100000}];]
{0.047,Null}
Timing[
Graphics[{PointSize[0.002],Point/@data},AspectRatio->Automatic]]
{0.157, -the graphic was here-}
By my watch, from typing Shift-Enter to seeing the result took 47 seconds.
Is that really "painfully slow"?
True, in 5.2 the graphic appears essentially instantly, although the
Timing value is 50% longer.
Szabolcs Horv=E1t wrote:
> In some cases, version 6 graphics can be painfully slow. Consider this
> example:
>
> data = Table[{Random[], Random[]}, {100000}];
> Graphics[{PointSize[0.002], Point /@ data}, AspectRatio -> Automatic] / /
> Show
>
> This used to work fine in version 5.2, but it takes forever to complete
> in version 6.0.1. I have a dataset with about 250 000 points that I
> would like to plot, so this problem is really annoying ...
>
> The strange thing is that as soon as the graphic appears, resizing is
> fast and works fine (especially with antialiasing disabled). So it is
> not the /drawing/ itself that takes so long.
>
> I really hope that these problems will be fixed in 6.1, but until then,
> does anyone have a suggestion for speeding this up?
>
> (At the moment I temporarily switch back to << Version5`Graphics`)
>
> Szabolcs
>
--
Murray Eisenberg mur...@math.umass.edu
Mathematics & Statistics Dept.
Lederle Graduate Research Tower phone 413 549-1020 (H)
University of Massachusetts 413 545-2859 (W)
710 North Pleasant Street fax 413 545-1801
Amherst, MA 01003-9305
thomas
I do have a solution, if your data is continuous (e.g. a time course
of some sort; the important feature of which being that no x-value
appears twice), and regularly spaced. Then your data can be
represented by the y-values alone; x<first> and x<last> are sufficient
to represent the span of the data.
I frequently have to plot that sort of data.
I do this by reducing the number of points plotted to 1000 (which
roughly is the number of pixels on the screen, and therefore
sufficient). I divide my data into 1000 blocks, find the Min and Max
of each block, and then represent each block by a vertical line
between min and max. This looks basically indistinguishable from a
ListLinePlot on the original data. I can give you the code snippet if
you are interested.
If your data is not so well-behaved, you might try to convert your
list of 2D coordinates into a packed array (if it not already is one;
your sample random data already is)
newList=Developer`ToPackedArray[list]
and then use
Point@newList
instead of Point/@newList in your Graphics. This will speed up things
like you never would imagine.
"@" instead of "/@" may already increase the speed without packing the
array (in other words, they time it takes to pack the array might
outweigh the speed you gain in the plotting, but I doubt it). Compare
the speed differences:
data = Table[{Random[], Random[]}, {100000}]; (*This is packed*)
data1 = Developer`FromPackedArray[data];(*This is not*)
and then
Graphics[{PointSize[0.002], Point@data}, AspectRatio ->
Automatic] // Show
or
Graphics[{PointSize[0.002], Point@data1}, AspectRatio ->
Automatic] // Show
The packed array plots much faster!
Good luck!
Thomas
Nasser Abbasi
"Szabolcs Horvát" <szho...@gmail.com> wrote in message
news:fmkerk$72g$1...@smc.vnet.net...
>
> In some cases, version 6 graphics can be painfully slow. Consider this
> example:
>
> data = Table[{Random[], Random[]}, {100000}];
> Graphics[{PointSize[0.002], Point /@ data}, AspectRatio -> Automatic] //
> Show
>
> This used to work fine in version 5.2, but it takes forever to complete
> in version 6.0.1. I have a dataset with about 250 000 points that I
> would like to plot, so this problem is really annoying ...
>
> The strange thing is that as soon as the graphic appears, resizing is
> fast and works fine (especially with antialiasing disabled). So it is
> not the /drawing/ itself that takes so long.
>
Well, I think it is the rendering of the Graphics to an image format for
display:
In[1]:= Timing[data = Table[{Random[], Random[]}, {100000}]][[1]]
Out[1]= 0.032
In[2]:= Timing[p = Graphics[{PointSize[0.002], Point /@ data},
AspectRatio -> Automatic]][[1]]
Out[2]= 0.062
In[3]:= t0 = TimeUsed[];
Show[p]
TimeUsed[] - t0
24.016
So it took 24 seconds to display the thing. But took fractions of second to
compute it.
It seems the "problem" is in the rendering by the Front End. i.e. by
converting the Graphics data structure to an image format. Or may be the FE
was waiting for the kernel, but Show[] should be all in the FE, so my guess
is the rendering part, or allocation of resources to render it is the
problem. For example, if I export the Graphics to an image file, I get the
same delay
In[15]:= t0 = TimeUsed[];
Export["t.png", p]
TimeUsed[] - t0
Out[17]= 23.75
May be the FE tells the kernel to convert the Graphics to image format and
the Kernel sends the image back to FE to display it, and so it could be the
kernel at fault also. Do not know details of the protocol.
> I really hope that these problems will be fixed in 6.1, but until then,
> does anyone have a suggestion for speeding this up?
>
> (At the moment I temporarily switch back to << Version5`Graphics`)
>
> Szabolcs
>
Nasser
Yves Klett
in 6.0x, Point (and Polygon) can take a list of points as arguments and
renders significantly faster:
data = Table[{Random[], Random[]}, {100000}];
Graphics[{PointSize[0.002], Point[data]},
AspectRatio -> Automatic] // Show
Regards,
Yves
Szabolcs Horvát schrieb:
ragfield
> In some cases, version 6 graphics can be painfully slow. =A0Consider this
> example:
>
> data = Table[{Random[], Random[]}, {100000}];
> Graphics[{PointSize[0.002], Point /@ data}, AspectRatio -> Automatic] //
> Show
>
> This used to work fine in version 5.2, but it takes forever to complete
> would like to plot, so this problem is really annoying ...
>
> The strange thing is that as soon as the graphic appears, resizing is
> not the /drawing/ itself that takes so long.
>
> I really hope that these problems will be fixed in 6.1, but until then,
> does anyone have a suggestion for speeding this up?
Your example runs in 73 seconds on my 4 year old desktop. If you wrap
Point[] around the entire array (rather than mapping it across the
array) it returns instantaneously.
Graphics[{PointSize[0.002], Point[data]}, AspectRatio -> Automatic]
See tutorial/EfficientRepresentationOfManyPrimitives in the
Mathematica 6 documentation.
-Rob
Nasser Abbasi
ref (me)
"Nasser Abbasi" <n...@12000.org> wrote in message news:...
>
....
>
> May be the FE tells the kernel to convert the Graphics to image format and
> the Kernel sends the image back to FE to display it, and so it could be
> the kernel at fault also. Do not know details of the protocol.
>
fyi, I just watched the Mathematica kernel during the Show[] command
In[3]:= t0 = TimeUsed[];
Show[p]
TimeUsed[] - t0
And the Kernel DOES get 100% CPU busy during all the time. So FE must be
sending the Graphics to the Kernel, and the Kernel converts to an image
format and send the image back to FE for display.
When I tried Graphics version 5, it indeed went very fast, the Kernel still
did some CPU, but the whole thing went very fast.
So, the problem seem in converting the Graphics to image format inside the
kernel for the FE to display it. They must have changed the algorithm or
something as such.
>> I really hope that these problems will be fixed in 6.1, but until then,
>> does anyone have a suggestion for speeding this up?
>>
>> (At the moment I temporarily switch back to << Version5`Graphics`)
>>
>> Szabolcs
>>
>
> Nasser
Szabolcs Horvát
As pointed out by several people, if the multi-coordinate form of
Point[] is used, plotting is just as fast as with version 5.
Szabolcs
Nasser Abbasi
>From: "John Fultz" <jfu...@wolfram.com>
>This theory is pretty far off from what actually happens.
Ok, but it is a theory, but it is based on solid observations :).
> In version 6, the kernel has absolutely no involvement whatsoever in
> generating the rendered
>image.
That is what I first said actually, it makes sense, but when I saw the
kernel going 100% CPU during the whole time the Show command was running,
and the FE was not using any CPU time, I thought that is what is happening.
(i.e. kernel is converting graphics to image)
I made a movie showing this on my PC (duel core intel CPU) in case someone
is interested, here it is (it is 16 MB AVI movie), where I type in the Show
command and have the windows CPU task manager up showing the CPU of the Math
kernel and the FE.
If you go to link below and click on the test3.avi file
http://12000.org/tmp/mathematica_kernel/
Thanks John for explaining in more details what is going on below and what
could be causing the CPU time for the kernel, very useful information. May
be more of these things can be written down in tutorials and added to
documentation center, under may be something like 'Mathematica design
internal' section for us users to read.
Nasser
"The steps taken in displaying a graphic in version 6 are very much like
those used in displaying non-graphical output. It works as follows:
1) The expression is evaluated, and ultimately produces something with head
Graphics[] or Graphics3D[].
2) The resulting expression is passed through MakeBoxes. MakeBoxes has a
set of
rules which turns the graphics expression into the box language which the
front
end uses to represent graphics. E.g.,
In[9]:= MakeBoxes[Graphics[{Point[{0, 0}]}], StandardForm]
Out[9]= GraphicsBox[{PointBox[{0, 0}]}]
Internally, we call this the "typeset" expression. It may be a little weird
thinking of graphics as being "typeset", but it's fundamentally the same
operation which happens for typesetting (which has worked this way for 11
years), so I'll use the term.
3) The resulting typeset expression is sent via MathLink to the front end.
4) The front end parses the typeset expression and creates internal objects
which generally have a one-to-one correspondence to the typeset expression.
5) The front end renders the internal objects.
In version 6, the front end, and only the front end can render graphics
(unless
you use the legacy PostScript scheme via <<Version5`Graphics`, in which the
kernel does the hard job of rendering the graphic to a simple subset of
PostScript, and the FE has the considerably easier job of merely rendering
the
PostScript to the screen).
There are three big opportunities for slowness to happen here if you don't
use
multi-points (i.e. a single Point with multiple coordinates):
* MakeBoxes has more work to do with a large table of Point[]'s than with a
Point[] of a large number of coordinates.
* The data transmission over MathLink is significantly more time-consuming
when
you're sending a large number of PointBox[] objects than when you're sending
a
single PointBox[] with a large number of coordinates.
* The front end has to construct a large number of internal PointBox[]
objects
separately rather than a single PointBox[] object with many coordinates.
The first two can contribute directly to the kernel CPU usage you're seeing.
I
don't know exactly in what proportion these three contribute to the slowness
(exercise for the reader if you're really that interested), but each does
make a
significant contribution.
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc."
sdw
it turns out that the front-end lets you edit graphics objects after
rendering - however, you can only select objects that have been sent as
individual objects. in this case, the entire collection of points can
be selected, but individual points cannot.
John Fultz
representing points. It requires only a small change to your code...
Graphics[{PointSize[0.002], Point[data]}, AspectRatio -> Automatic]
I.e.,
Point[{list of points}]
rather than
{Point[{pt1}], Point[{pt2}], ...}
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.
On Wed, 16 Jan 2008 03:20:38 -0500 (EST), Szabolcs Horv=E1t wrote:
>
>
> In some cases, version 6 graphics can be painfully slow. Consider this
> example:
>
> data = Table[{Random[], Random[]}, {100000}];
> Graphics[{PointSize[0.002], Point /@ data}, AspectRatio -> Automatic] //
> Show
>
> This used to work fine in version 5.2, but it takes forever to complete
> in version 6.0.1. I have a dataset with about 250 000 points that I
> would like to plot, so this problem is really annoying ...
>
> The strange thing is that as soon as the graphic appears, resizing is
> fast and works fine (especially with antialiasing disabled). So it is
> not the /drawing/ itself that takes so long.
>
John Fultz
kernel has absolutely no involvement whatsoever in generating the rendered
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.
On Thu, 17 Jan 2008 06:59:59 -0500 (EST), Nasser Abbasi wrote:
>
>
> ref (me)
>
> "Nasser Abbasi" <n...@12000.org> wrote in message news:...
>
> ...
>
>> May be the FE tells the kernel to convert the Graphics to image format
>> and
>> the Kernel sends the image back to FE to display it, and so it could be
>> the kernel at fault also. Do not know details of the protocol.
>>
>
> fyi, I just watched the Mathematica kernel during the Show[] command
>
> In[3]:= t0 = TimeUsed[];
> Show[p]
> TimeUsed[] - t0
>
> And the Kernel DOES get 100% CPU busy during all the time. So FE must be
> sending the Graphics to the Kernel, and the Kernel converts to an image
> format and send the image back to FE for display.
>
> When I tried Graphics version 5, it indeed went very fast, the Kernel
> still
> did some CPU, but the whole thing went very fast.
>
> So, the problem seem in converting the Graphics to image format inside the
> kernel for the FE to display it. They must have changed the algorithm or
> something as such.
>
>
>>> I really hope that these problems will be fixed in 6.1, but until
>>> then,
>>> does anyone have a suggestion for speeding this up?
>>>
>>> (At the moment I temporarily switch back to << Version5`Graphics`)
>>>
>>> Szabolcs
>>>
>>
>> Nasser