On Mon, 13 Dec 2010 22:19:45 +0100 Udo Richter <udo_richter@xxxxxx> wrote: > Am 13.12.2010 11:34, schrieb Steffen Barszus: > > That was my point in the beginning. Then: I want to see sqlite3 > > being less efficient on insert and fetch or memory consumption. I > > can not imagine it (prove me wrong! ;)). > > Correct me if I'm wrong, but for sqlite you'll have to convert all > these nice epg data structures into sql commands that need to be > passed to the sql engine where an sql interpreter tears everything > apart again for (possibly) on-disk storage, and for querying epg, the > whole sql interpreter thing goes backwards again, or? I'm not too sure - as my DB experience is only with something bigger then sqlite. But i think, if done correctly, you have a couple of prepared statements which you can re-use with bind variables. Then taking into account that sqlite3 should be quite optimized for what its doing, and (which i would not want) you can have in memory db. > Never under-estimate a native C/C++ coded data structure, at least if > it's a smart one. Reading/writing to a tree or hash might be done > before the sql interpreter even starts. Never underestimate the comfort you will get with not re-inventing the wheel ;). > (not that the VDR internal structures are that impressive fast, > though. I wonder how much it would gain by using C++ map and similar.) My point for suggesting sqlite was not only performance (which i can not estimate where vdr stands) - but also removing the blackbox of the in memory handling, and the handcrafted file format. _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
