On Wed, May 27, 2009 at 08:25:32PM +0200, Bernhard Reutner-Fischer wrote: >On Tue, May 26, 2009 at 01:42:57PM +0200, Tobias Oetiker wrote: >>Hi Bernhard, >> >>Today Bernhard Reutner-Fischer wrote: >> >>> On Tue, May 26, 2009 at 09:17:59AM +0200, Tobias Oetiker wrote: >>> >>> >finally getting ready to publish 1.4rc I have resolved the >>> >>> btw.. Can we please have cf_conv exported since otherwise >>> it is not really possible to do anything useful with the >>> library. >> >>:-) interesting notion ... you mean all uses of the library up to >>now have not been useful ? > >I don't know, but my usecase needs it exported from the beginning. >I admit that i have _no_ idea how other users of the library >look like, but i wouldn't be surprised if they were just using >some high-level view without having to worry about performance :) >> >>please elaborate. > >Suppose i want to get some values out of an rrd (like i mentioned before >in the sample-code here ¹) in the _fastest_ possible way and you have an > rrd with say X ds and Y cf and only want to get ds_something with cf >LAST, then you somehow need to get at the appropriate data. > >Note, that i cannot afford to waste any unwarranted cycles to get at that >data, so high-level scripting languages and stuff like that are a nono, >I have to rrd_open() the file, get at the data and interpret the values >often, very often and as fast as possible. Since i need only current >data in 99.9% of the accesses (and no older data), it of course helped >to also keep the "hot" regions in memory as much as possible. But anyway. > >I would be more than happy to be able to reuse more of the existing >code of librrd as you can see about all except the setup and reporting >in the sample application is just taken 1:1 from rrd_fetch() (IIRC). > >See? > >¹) > http://www.google.at/search?hl=en&num=50&q=rrd_reader&btnG=Search
I've put my current incarnation here, fyi: wget -cN http://busybox.net/~aldot/rrdtool/rrd_reader.{c,h} && \ gcc -O2 $CFLAGS -o rrd_reader rrd_reader.c -I/opt/rrdtool/include rrdtool-1.4, user-friendly C API, platform independent format sound somehow familiar :) If you're thinking about doing an 1.4-rc, then i encourage you to look at the sample user above. Ideally, such a thing would just consist of (quote from ¹ above): ---8<--- You can see how i had to: a) duplicate basically all of rrd_format.h b) had to duplicate those parts of fetching values that deal with the calculation of the locus of the data we need. The applet should basically do this instead: 0) [APP] option handling 1) call rrd_open() 2) [APP] eventually inspect the header. 3) [APP] setup desired start, end, step. 4) call rrd_find_rra() or rrd_find_best_rra() /* or however it would be called */ 5) [APP] adjust start, end, step to legit values. 6) call rrd_fetch_fn() 7) [APP] rrd_close(); rrd_free() 8) [APP] do something with the results and exit. Where stuff marked with [APP] is ok to be done by the application, but the rest (points 1, 4, 6) should be just simple calls into librrd. ---8<--- http://www.nabble.com/-PATCH-%2B-RFC--Cleanup-the-symbols-exported-by-librrd.-tt17719839.html#a17732207 cheers, Bernhard _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers