On Thu, May 24, 2007 at 05:46:12PM +0200, Bernhard Fischer wrote: >>I still see implicit decls of chroot and (from rrd_graph.c) implicit >>decls of localtime_r and tzset, fwiw. > >Then there are those redefinitions when building the perl wrapper. >I take it that we cannot simply use the CC that was given by the user to >build the perl module, right? >If we have to use the perl-given CC, then we have to re-check all our >options against the perl CC, which may or may not result in inconsistent >builds as far as the wrapper versus the real rrdtool is concerned. > >Therefor, i suggest to build the perl wrapper with the CC which we used >to build rrdtool. Opinions? > >For the most part, the changes are now done¹) (checked FD-based vs. mmap >based vs. vanilla 1.2.23-mmap for 'last', 'fetch' and 'dump'), from my >POV. This means that the fine-tuning can start (finally, yay! :). > >Does somebody have a sequence of creating a dummy rrd, and (manually!) >doing rrd_update()s on it, by chance?
This is the most important thing which is still outstanding. Sit down and make rrd_update as fast as possible. The fadvise approach (against 1.0.49 (!) which sounds a little bit odd to me ;) is nice and all, but we should be able to do better than that. > >¹) One thing that i still want to repair is the "librrd vs. rrd.h -- >incomplete interface", as described here: >https://lists.oetiker.ch/pipermail/rrd-developers/2007-May/001869.html Some additional, random TODOs: - janitorial cleanups There is quite some opportunity for janitorial code-cleanups, IMO. Error pathes come to mind. - have to use rrd_close (which should call rrd_free()) everywhere. This is currently not done at all (we let the kernel do the cleanup for now, but this will have to be done properly anyway) as i was too lazy.. These two could go hand in hand, obviously. cheers, Bernhard _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers