Performance analysis

As a preparatory step for changing the Atlas map, Marble’s vector graphics painter, the GeoPainter, needs to be tested and optimized as much as possible, by loading big KML files, using different filtering methods and comparing the results. Keeping in mind that even the longest and hardest journeys start with a single step, guess what I had to do first: of course, a tutorial 🙂

This one teaches you how to load a KML file into a Marble Widget. The process is quite easy once you know a few tricks regarding the Marble Widget ( a good idea to learn them would be to go through all the tutorials ), you can see here how to load a file, add it to Marble’s tree model and display it.

Once I learned how to load files into the widget, tackat prepared a KML containing a huge line string ( around 600.000 nodes ) in order to test GeoPainter’s speed. The line string represents the Appalachian Trail, and looks like this ( the blue line ):

For measuring GeoPainter’s performance, I had to “install” two timers ( thank you QTime ) inside the GeoPainter class: one for the entire drawPolyLine() method, and the other one for createPolygonsFromLineString()’s method call inside drawPolyLine(), since that is the major time consumer.

The first test I did was on the unfiltered line string, while the following ones employed different more or less sophisticated algorithms. So I set my widget on the Spherical projection, Plain map and a zoom level of 1500 and started testing. The drawing times I obtained ( with no music on the background, youtube seems to keep my processors too busy for accurate tests 🙂 ) can be seen below. Time elapsed represents the time for the entire drawPolyLine() method, Create polygons time shows for how long lasted the call to createPolygonsFromLineString() and Nodes is the number of points in the line string.

Create polygons time: 25 ms
Time elapsed: 111 ms Nodes: 624072

Create polygons time: 41 ms
Time elapsed: 93 ms Nodes: 624072

Create polygons time: 34 ms
Time elapsed: 169 ms Nodes: 624072

Create polygons time: 27 ms
Time elapsed: 112 ms Nodes: 624072

Create polygons time: 26 ms
Time elapsed: 138 ms Nodes: 624072

In the next posts I am going to present the (better yaay 🙂 ) results obtained by using some filtering methods on the line string.

 

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Performance analysis

  1. Milian Wolff says:

    This performance analysis is flawed in so many ways…

    First up, you should extract the interesting stuff into an easily reproducible test case that can be run without human interaction. This ensures that you can safely compare before/after numbers.

    Now, while QElapsedTimer *can* be helpful sometimes, I strongly advise against using it if at all possible. Instead, use callgrind from valgrind which gives you 100% reproducible and comparable numbers (it’s just an instruction counter, basically) – this way you can also leave normal apps running in the background, they won’t interfer with it. Alternatively, and I came to using that more and more as it’s much faster (less introspection overhead), try out VTune. It is free-for-non-commercial-use on Linux and thus a perfect fit for KDE development. It’s UI makes it quite straight forward where your bottlenecks lie and thus where to optimize. It is sampling based though, and hence system load can have an effect. On a semi-modern multi-core system this is rarely an issue though, if you just listen to some music and don’t have CPU or IO-intensive tasks running.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s