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 e.g.: http://www.google.at/search?hl=en&num=50&q=rrd_reader&btnG=Search _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
