[Nepomuk] [Soprano-devel] Benchmarking storage backends

[Ben Martin]

On Mon, 2009-10-26 at 11:35 +0100, Sebastian Trüg wrote: 
> On Friday 23 October 2009 14:36:42 Ben Martin wrote:
> > On Thu, 2009-10-22 at 13:22 +0200, Sebastian Trüg wrote:
> > > On Thursday 22 October 2009 12:43:55 Ben Martin wrote:
> > > > Hi,
> > > >   As I'm tinkering with a new backend design for soprano I'm wondering
> > > > what folks use to benchmark nepomuk for KDE4 usage?
> > > >
> > > >   Do folks just use the generic RDF benchmarking:
> > > > http://esw.w3.org/topic/RdfStoreBenchmarking
> > > > when comparing sesame2 to virtuoso backend for example?
> > >
> > > folks, in this case me, don't do much benchmarking at all. So far there
> > > was no real need for it since there has never been any choice: in the
> > > beginning we only had redland. You know that it is slow by using it for a
> > > few days. No need for a benchmark. Then we had sesame2 which is
> > > deprecated by Virtuoso simply because the latter has so many advantages.
> > > Performance is not even in the top 5. ;)
> > 
> > The two main areas that I'm targeting with my memory mapped soprano
> > backend are as a quick, read only, in process cache for desktop and for
> > embedded or pseudo embedded targets like the maemo.
> 
> right, but how does a read-only backend help us in Nepomuk?

There is of course no reason that the memory mapped design can not
handle writes too. Its just that there needs to be some smarts there to
make sure that multiple processes don't stomp on each other. I have a
few designs to allow that to happen, but getting that code whipped up
and committed will likely take quite a few sunday afternoons.

The design is that reads should be extremely fast, writes (from multiple
processes at once) will be supported at some point. Writes from a single
process are already supported and are very quick because there is no
overhead for process synchronizations.

> 
> > I can definitely see the attraction to Virtuoso on the desktop / LAN but
> > for mobile devices V might not be available :|
> 
> Well, I think that mobile devices in a year or two should not have a problem 
> with 50Mb of ram usage.

Ah, famous last words ;) But even if maemo devices get 512mb+ there will
always be the soft target of symbian phones with soprano on top of Qt. I
would imagine that RAM constraints will always be highest on such
devices. Of course, if the virtuoso backend on n900 / n1000 is efficient
and RAM friendly then the mmap backend can just become an academic
curiosity.

> 
> Cheers,
> Sebastian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20091026/ba1a0d21/attachment.sig