On Mon, 13 Dec 2010 22:19:45 +0100 Udo Richter udo_richter@gmx.de 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.