Hi All, I have spent considerable time improving the graph performance in the latest 1.4.x editions ...
one major cause of slowdown was 'font selection'. Depending on the number of fonts on your system this can take a long time ... if you generate multiple graphs with a single instance of rrdtool (eg by using it via the language bindings or with the pipe interface) the fonts will be cached between invocations and the performance impact occures only once ... a second source of slowdown is the gzip compression applied to the png file ... with gzip level 1 graphs would be created much more quickly ... unfortunately cairo does not provide access to this setting of libpng.. to recap a) use 1.4.8 b) use language bindings or the pipe interface c) create a patch so that rrdtool uses cairo to just fill an image buffer and then pass the buffer on to libpng directly for fast compression. The code for this can be found in 1.3.x where this was necessary because the graphing library did not provide png output capabilities internally. hth tobi Today Sebastian Harl wrote: > tags 419948 + wontfix > thanks > > This bug had not seen any activity in year. It seems rather unlikely > that any resources will be spent on this and further tracking it does > not make sense imho. > > Also note that there are some ideas around redesigning RRDtool from the > ground up -- see https://github.com/oetiker/rrdtool-2.x > > On Sun, Mar 21, 2010 at 05:17:16PM +0100, Sebastian Harl wrote: > > Hi Florian and Carl, > > > > (This is a follow-up to Debian bug report #419948 -- see > > <http://bugs.debian.org/419948> for details.) > > > > On Wed, Sep 30, 2009 at 09:54:06PM +0200, Sebastian Harl wrote: > > > On Mon, Sep 28, 2009 at 10:32:52AM +0200, Florian Schlichting wrote: > > > > On Thu, Sep 24, 2009 at 06:17:55PM +0200, Sebastian Harl wrote: > > > > > Okay, so it seems we've got a rather major speed-down in rrdgraph > > > > > Sarge > > > > > -> Etch (RRDtool 1.0 -> 1.2) and another one Etch -> Lenny (RRDtool > > > > > 1.2 -> > > > > > 1.3). In the former case, RRDtool switched from using libgd to libart > > > > > for doing the graphing, in the latter case, they switched to libcairo > > > > > (and libpango). I'm pretty sure, the speed-down is related to that. In > > > > > the course of the 1.3.x releases some optimizations have been applied > > > > > which improved the effect a bit but there still is a notable > > > > > speed-down. > > > > > > > > > > Anyway, frankly, I've got no idea what to do about that. > > > > > > > > well, I think that's a good explanation. So it's not a "bug", but an > > > > intentional design decision with not-so-intentional side effects. > > [?] > > > > I don't know about upstream's motivation for those switches, but > > > > perhaps it would be worthwhile to benchmark graphing with the > > > > different libraries / RRDtool versions and reevaluate their merits in > > > > that light? > > > > > > I'm not sure about the motivations either :-/ Benchmarks would be really > > > great. Are you willing to take care of that? > > > > Does anyone of you happen to have some benchmarks available (or could > > you rather easily get any)? > > > > With this E-mail, I'm also forwarding the bug upstream (this should have > > happened long ago :-/ ), hoping for some more input / suggestions / > > further ideas. > > > > Cheers, > > Sebastian > > > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch t...@oetiker.ch +41 62 775 9902 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
