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