{"id":249,"date":"2015-06-09T15:35:25","date_gmt":"2015-06-09T19:35:25","guid":{"rendered":"https:\/\/blogs.mathworks.com\/graphics\/?p=249"},"modified":"2015-06-09T15:35:25","modified_gmt":"2015-06-09T19:35:25","slug":"object-creation-performance","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/graphics\/2015\/06\/09\/object-creation-performance\/","title":{"rendered":"Object Creation Performance"},"content":{"rendered":"

Object Creation Performance<\/h3>

Back in January, we looked at the performance of creating a graphics object with a lot of data<\/a>. Today we're going to look at what is basically the opposite problem. What does the performance look like when we're creating a lot of graphics objects which each have a tiny amount of data?<\/p>

In general, creating a large number of graphics objects which each have a small amount of data is going to be slower than creating a small number of graphics objects with a large amount of data.<\/p>

We can see this pretty easily with the following example. I want to draw a thousand markers along this curve:<\/p>

\"$$exp(i<\/p>

t = linspace(0,2*pi,1000);\r\nv = exp(i*t) - exp(6*i*t)\/2 + i*exp(-14*i*t)\/3;\r\nx = real(v);\r\ny = imag(v);\r\n<\/pre>
I could do this with 1,000 calls to scatter:<\/p>
axes\r\nhold on<\/span>\r\ns = 10;\r\ndrawnow\r\ntic\r\nfor<\/span> ix=1:1000\r\n   scatter(x(ix),y(ix),s,t(ix),'filled'<\/span>);\r\nend<\/span>\r\ndrawnow\r\ntoc\r\n<\/pre>
Elapsed time is 7.610161 seconds.\r\n<\/pre>\"\" 
Or I could do it with a single call to scatter:<\/p>
hold off<\/span>\r\ncla\r\ndrawnow\r\ntic\r\nscatter(x,y,s,t,'filled'<\/span>)\r\ndrawnow\r\ntoc\r\n<\/pre>
Elapsed time is 0.056938 seconds.\r\n<\/pre>\"\" 
As you can see, creating a single scatter object with 1,000 points is about 150 times faster than creating 1,000 scatter objects which each have a single point.<\/p>
But I want to generalize this and look at how it scales over different types and numbers of objects.<\/p>
Lets start drilling into this by looking at the cost of creating 400 random lines. To get accurate data, I'll run this 15 times. That's because, as we'll see in a moment, there tends to be a bit of noise in these measurements. That's caused by other things running on the machine, where things are located in memory, and other things like that.<\/p>
clf\r\ndrawnow\r\nnpass = 15;\r\nresults = zeros(1,npass);\r\nx1 = rand(1,400);\r\nx2 = rand(1,400);\r\ny1 = rand(1,400);\r\ny2 = rand(1,400);\r\nfor<\/span> ix=1:npass\r\n    cla\r\n    drawnow\r\n    tic\r\n    for<\/span> j=1:400\r\n        line([x1(j) x2(j)],[y1(j) y2(j)])\r\n    end<\/span>\r\n    drawnow\r\n    results(ix) = toc;\r\nend<\/span>\r\n<\/pre>\"\" 
I prefer to look at this type of data as 'Number of objects created per second', so we'll look at the number of objects divided by the time.<\/p>
And we'll also want to look at the median of those 15 runs. The median is the best choice here because it's relatively insensitive to anomalies where one run \"hiccups\" because something else on the machine got resources.<\/p>
grey = [.75 .75 .75];\r\nplot(1:npass,400.\/results)\r\nxlabel('Run #'<\/span>)\r\nylabel('Line objects per second'<\/span>)\r\nmin_lines_per_second = min(400.\/results);\r\nmedian_lines_per_second = median(400.\/results)\r\nmax_lines_per_second = max(400.\/results);\r\nline([1 15],repmat(min_lines_per_second,[1 2]),'Color'<\/span>,grey)\r\nline([1 15],repmat(median_lines_per_second,[1 2]),'Color'<\/span>,'green'<\/span>,'LineWidth'<\/span>,2)\r\nline([1 15],repmat(max_lines_per_second,[1 2]),'Color'<\/span>,grey)\r\nylim([0 inf])\r\n<\/pre>
\r\nmedian_lines_per_second =\r\n\r\n   1.8366e+03\r\n\r\n<\/pre>\"\" 
So the median is about 1,800 line objects per second.<\/p>
But as I said when we were looking at the large data case, it's always good to take a look at how performance scales with different size problems. I ran this same code, varying the number of objects from 0 to 500. I did 4 runs at each size and then saved the median values to a MAT file. You can see that there's still a bit of noise, but this is good enough to work with.<\/p>
load R2015a_creation_results<\/span>\r\nplot(R2015a_creation_results.counts,R2015a_creation_results.counts.\/R2015a_creation_results.line_times);\r\nhold on<\/span>\r\nerrorbar(400,median_lines_per_second,median_lines_per_second-min_lines_per_second,max_lines_per_second-median_lines_per_second,'Color'<\/span>,'red'<\/span>)\r\nxlabel('# of objects'<\/span>)\r\nylabel('Objects per second'<\/span>)\r\n<\/pre>\"\" 
That looks pretty good. We can see that there's some startup cost, as we saw when scaling the amount of data, but we're pretty close to full speed once we get to about 150 objects.<\/p>
Now that we've measured the performance of creating a graphics object, what can we do to speed it up when it's the bottleneck? The best thing we can do is obviously to create fewer objects, but how?<\/p>
If you remember the post where I talked about performance scaling<\/a>, then you may remember that the left side of the performance curves was flat. This means that the time it takes to create a line object with 2 points is pretty much the same as the time it takes to create a line object with 10,000 points. We can actually take advantange of that here by using a very old MATLAB graphics programming trick.<\/p>
The basic idea is that you can put nan values into the X & Y data to break a line into multiple segments. To do this, we want to create arrays that look like this:<\/p>
x3 = [x1(1), x2(1), nan, x1(2), x2(2), nan, x1(3), x2(3), nan, ...<\/span>\r\ny3 = [y1(1), y2(1), nan, y1(2), y2(2), nan, y1(3), y2(3), nan, ...<\/span>\r\n<\/pre>
That's actually pretty easily done:<\/p>
for<\/span> ix=1:npass\r\n    cla\r\n    drawnow\r\n    tic\r\n    x3 = [x1; x2; nan(1,400)];\r\n    y3 = [y1; y2; nan(1,400)];\r\n    x3 = x3(:);\r\n    y3 = y3(:);\r\n    line(x3,y3)\r\n    drawnow\r\n    results(ix) = toc;\r\nend<\/span>\r\n<\/pre>\"\" 
The performance of doing it this way is much, much better!<\/p>
plot(1:npass,400.\/results)\r\nxlabel('Run #'<\/span>)\r\nylabel('Line segments per second'<\/span>)\r\nmin_lines_per_second = min(400.\/results);\r\nmedian_lines_per_second = median(400.\/results)\r\nmax_lines_per_second = max(400.\/results);\r\nline([1 15],repmat(min_lines_per_second,[1 2]),'Color'<\/span>,grey)\r\nline([1 15],repmat(median_lines_per_second,[1 2]),'Color'<\/span>,'green'<\/span>,'LineWidth'<\/span>,2)\r\nline([1 15],repmat(max_lines_per_second,[1 2]),'Color'<\/span>,grey)\r\nylim([0 inf])\r\n<\/pre>
\r\nmedian_lines_per_second =\r\n\r\n   3.5182e+04\r\n\r\n<\/pre>\"\" 
Well that certainly helped. We've gone from 1,800 lines per second up to 35,000 lines per second. That's almost a 20X speedup!<\/p>
The problem with this old trick is that it isn't a one size fits all solution. You need to do things a little differently for different types of graphics objects. So we'll look at a couple of different types of graphics objects. While we do that, let's also look at the object creation performance in different versions of MATLAB.<\/p>
Here's some data I collected for creating 7 different types of objects in each of the last 3 versions of MATLAB.<\/p>
clf\r\nload R2014a_create400_results<\/span>\r\nload R2014b_create400_results<\/span>\r\nload R2015a_create400_results<\/span>\r\nload R2015b_Prerelease_create400_results<\/span>\r\nplot_create400(R2014a_create400_results, ...<\/span>\r\n               R2014b_create400_results, ...<\/span>\r\n               R2015a_create400_results)\r\nlegend('R2014a'<\/span>,'R2014b'<\/span>,'R2015a'<\/span>)\r\ntitle('Graphics Object Creation Performance'<\/span>)\r\n<\/pre>\"\" 
There's a lot going on in this chart. The first thing that we notice is that object creation took a big performance hit when the new graphics system was introduced in R2014b. That's because when the graphics objects got converted to real MATLAB classes, they lost a bunch of the performance tweaks that had been added to the old graphics system over the decades.<\/p>
We can also see that the amount of slowdown depends on the type of object. It varies from taking taking about 40% longer to create an image, to taking about 7 times as long to create an axes. Both of those extremes are actually special cases. For most of the graphics objects (such as the line), the slowdown was about 4 times as long. We're slowly adding performance tweaks back into the new objects, as you can see for the line and text object in R2015a, but it will be quite a while before it catches up with the old system. This means that in any case where you need performance, you're going to want to optimize your code so you're not creating too many graphics objects. This was a good idea in earlier versions of MATLAB, but it is even more important in newer versions.<\/p>
OK, so lets go back to our combining objects trick. The first thing to note is that it was already a good idea in older versions of MATLAB. That's why that trick of putting nans in to combine lines is an \"old trick\".<\/p>
But how can we use the combining trick with these other objects?<\/p>
We've already seen how to combine calls to scatter and line. Patch is just a little bit trickier. If we're using the Face\/Vertex form of patch, we can just concatenate the Vertices array, but we need to add an offset to one of the Faces arrays. So this:<\/p>
clf\r\ndrawnow\r\ntic\r\nfor<\/span> ix=0:99\r\n    a1 =  ix   *2*pi\/100;\r\n    a2 = (ix+1)*2*pi\/100;\r\n    v = [cos(a1), sin(a1), -1; ...<\/span>\r\n         cos(a2), sin(a2), -1; ...<\/span>\r\n         cos(a2), sin(a2),  1; ...<\/span>\r\n         cos(a1), sin(a1),  1];\r\n    f = 1:4;\r\n    patch('Vertices'<\/span>,v,'Faces'<\/span>,f,'FaceColor'<\/span>,'yellow'<\/span>);\r\nend<\/span>\r\nview(3)\r\ndrawnow\r\ntoc\r\n<\/pre>
Elapsed time is 0.111010 seconds.\r\n<\/pre>\"\" 
Becomes this:<\/p>
clf\r\ndrawnow\r\ntic\r\nverts = [];\r\nfaces = [];\r\nfor<\/span> ix=0:99\r\n    a1 =  ix   *2*pi\/100;\r\n    a2 = (ix+1)*2*pi\/100;\r\n    v = [cos(a1), sin(a1), -1; ...<\/span>\r\n         cos(a2), sin(a2), -1; ...<\/span>\r\n         cos(a2), sin(a2),  1; ...<\/span>\r\n         cos(a1), sin(a1),  1];\r\n    f = 1:4;\r\n    verts = [verts; v];\r\n    faces = [faces; f + 4*ix];\r\nend<\/span>\r\npatch('Vertices'<\/span>,verts,'Faces'<\/span>,faces,'FaceColor'<\/span>,'yellow'<\/span>)\r\nview(3)\r\ndrawnow\r\ntoc\r\n<\/pre>
Elapsed time is 0.026823 seconds.\r\n<\/pre>\"\" 
Some of the others types of objects can be harder to combine though. The most important one is the axes. As we saw above, creating axes slowed down quite a bit in R2014b. That's largly because we've added a lot of features to the new version of axes. You've seen a couple of those features in the last two releases, but you'll be seeing a lot more of them when R2015b comes out this summer.<\/p>
There are basically two different ways in which axes objects are used. The first is to actually use them as an axes to hold a chart. In this case, you want the ticks and labels and things. The other case is just as a container to draw something in. In this second case, you usually turn the Visible property of the axes off.<\/p>
There isn't a lot you can do to combine axes in the first case. The subplot command will create a grid of axes, but it does that by actually creating a bunch of axes objects, so there isn't a shortcut there. The good news is that you usually don't create an awful lot of axes objects when you use them this way. Creating 400 axes objects in a single figure usually results in them being too small to read.<\/p>
But in the second case, where we're turning the Visible property off, it often is pretty easy to combine several axes into a single object. Let's look at an example.<\/p>
Here is an example from the MATLAB newsgroup.<\/p>
fw = 640;\r\nfh = 640;\r\nfig = figure('Units'<\/span>,'pixels'<\/span>,'Position'<\/span>,[0 0 fw fh]);\r\nnRows = 40;\r\nnKols = 10;\r\nheight = (fh-2)\/nRows;\r\nwidth = (fw-2)\/nKols;\r\ntic\r\nfor<\/span> iRow = 1:nRows\r\n    for<\/span> iKol = 1:nKols\r\n        axes('Units'<\/span>,'pixels'<\/span>,'Position'<\/span>,[1+(iKol-1)*width, fh-iRow*height, width, height], ...<\/span>\r\n             'Visible'<\/span>,'off'<\/span>);\r\n        text(.5,.5,['Ax '<\/span>, num2str(iRow), ','<\/span>, num2str(iKol)], ...<\/span>\r\n             'HorizontalAlignment'<\/span>,'center'<\/span>)\r\n    end<\/span>\r\nend<\/span>\r\ndrawnow\r\ntoc\r\n<\/pre>
Elapsed time is 1.807279 seconds.\r\n<\/pre>\"\" 
It's actually pretty easy to turn that into a single axes with a bunch of text objects in it:<\/p>
delete(fig)\r\nfig = figure('Units'<\/span>,'pixels'<\/span>,'Position'<\/span>,[0 0 fw fh]);\r\ntic\r\naxes('Position'<\/span>,[0 0 1 1],'Visible'<\/span>,'off'<\/span>)\r\nxlim([1 fw])\r\nylim([1 fh])\r\nfor<\/span> iRow = 1:nRows\r\n    for<\/span> iKol = 1:nKols\r\n        text(1+(iKol-.5)*width, fh-(iRow-.5)*height, ...<\/span>\r\n             ['Ax '<\/span>, num2str(iRow), ','<\/span>, num2str(iKol)], ...<\/span>\r\n             'HorizontalAlignment'<\/span>,'center'<\/span>)\r\n    end<\/span>\r\nend<\/span>\r\ndrawnow\r\ntoc\r\n<\/pre>
Elapsed time is 0.567477 seconds.\r\n<\/pre>\"\" 
That helps quite a bit, but we've still got all of those text objects. Unfortunately those are a lot harder to combine. We can combine all of the strings in one column by using a cell array:<\/p>
delete(fig)\r\n%clf<\/span>\r\nfig = figure('Units'<\/span>,'pixels'<\/span>,'Position'<\/span>,[0 0 fw fh]);\r\ntic\r\naxes('Position'<\/span>,[0 0 1 1],'Visible'<\/span>,'off'<\/span>)\r\nxlim([1 fw])\r\nylim([1 fh])\r\nfor<\/span> iKol = 1:nKols\r\n    strings = {};\r\n    for<\/span> iRow = 1:nRows\r\n        strings{end+1} = ['Ax '<\/span>, num2str(iRow), ','<\/span>, num2str(iKol)];\r\n    end<\/span>\r\n    text(1+(iKol-.5)*width, fw\/2, strings, ...<\/span>\r\n             'HorizontalAlignment'<\/span>,'center'<\/span>, ...<\/span>\r\n             'VerticalAlignment'<\/span>,'middle'<\/span>);\r\nend<\/span>\r\ndrawnow\r\ntoc\r\n<\/pre>
Elapsed time is 0.175428 seconds.\r\n<\/pre>\"\" 
But as you can see, this isn't a perfect fix because it can be really hard to accurately control the vertical spacing. That means that you're only going to be able to use this approach for text in some special cases. You may find that the performance gain isn't enough to make up for the lose of placement control.<\/p>
Both image and surface can also be tricky to combine into a single object. So the approach of combining several graphics objects into a single one isn't a perfect solution to the problem of object creation performance, but it is an important technique to know about when you're trying to make your MATLAB Graphics code run as fast as possible.<\/p>