[rrd-users] RRD graph/xport performance

[Ryan Kubica]

Thanks, I'll look into callgrind.

This slowness hasn't anything to do with fonts, legends or the like ... it's a simple matter of a progressive slowdown and huge memory consumption as datasources increase.

Thanks again,
-Ryan


________________________________
 From: Tobias Oetiker <tobi at oetiker.ch>
To: Ryan Kubica <kubicaryan at yahoo.com> 
Cc: "rrd-users at lists.oetiker.ch" <rrd-users at lists.oetiker.ch> 
Sent: Sunday, August 12, 2012 2:15 AM
Subject: Re: [rrd-users] RRD graph/xport performance
 
Hi Ryan

Today Ryan Kubica wrote:

> I'm curious what benchmarks/tracing you do during development to
> localize performance bottlenecks in rrdtool graphing.

rrdtool graphing relies a lot on services provided by other
libraries in the first instance this is cairo / pango, but further
down the chain also freetype, libpng and zlib

I have used callgrind (part of valgrind) to pinpoint performance
issues ...

I found that the handling of truetype fonts can easily lead to
performance issues, especially on systems with large numbers of
fonts available to the fontconfig libraries. I have tried to make
sure in rrdtool code that all the caching that available in this
regard is employed, but this will only have an effect if you
produce multiple charts from the same process

Another timesink is the graph compression as mentioned in a
previous posst.

If you are using xport instead of graph or use graph without
actually generating a graph, the perfromance bottlenecks will be
different ... (I have not investigated this).

I have never looked at RPN processing performance for example, so
there might be some easy wins there.

As mentioned at the beginnnig, I find callgrind invaluable
in this respect

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20120812/26a1fd55/attachment.htm