[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nepomuk
Subject:    Re: [Nepomuk] Why store file urls?
From:       Vishesh Handa <me () vhanda ! in>
Date:       2012-11-23 9:20:43
Message-ID: CAOPTMKDS1MZPxxM2NdFJFgvhqaQvWSU=qNFg6CdATo2y1syzpw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Fri, Nov 23, 2012 at 2:25 PM, Anders Lund <anders@alweb.dk> wrote:

> On Fredag den 23. november 2012 14:16:22 Vishesh Handa wrote:
> > The problem with this approach is that every single url which is passed
> > through Nepomuk needs to be checked for the "filex" scheme and then
> > translated. Since we do not have a sparql parser this is done by
> employing
> > regular expressions to check for patterns with file:/mount/point and
> filex.
> >
> > Valgrind logs show that for small queries a sizable amount (upto 40%) of
> > time is spent in just this regular expression based parsing. Additionally
> > since queries can return any kind of data, all of the data passed from
> > virtuoso to Nepomuk has go through these checks.
>
> Why use regular expressions to search for a fixed string? Simple string
> comparison would be much more efficient for that!
>

My bad. We do not use regular expressions. We instead look through the
entire query and try to pick up patterns by simple string comparisons.

The relevant code can be found at
nepomuk-core/services/storage/removeablemediamodel.cpp - convertFilexUrl
and converFileUrls functions.


>
>
> --
> Anders
> _______________________________________________
> Nepomuk mailing list
> Nepomuk@kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>



-- 
Vishesh Handa

[Attachment #5 (text/html)]

<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 23, 2012 at \
2:25 PM, Anders Lund <span dir="ltr">&lt;<a href="mailto:anders@alweb.dk" \
target="_blank">anders@alweb.dk</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div class="im">On Fredag den 23. november 2012 14:16:22 \
Vishesh Handa wrote:<br> &gt; The problem with this approach is that every single url \
which is passed<br> &gt; through Nepomuk needs to be checked for the \
&quot;filex&quot; scheme and then<br> &gt; translated. Since we do not have a sparql \
parser this is done by employing<br> &gt; regular expressions to check for patterns \
with file:/mount/point and filex.<br> &gt;<br>
&gt; Valgrind logs show that for small queries a sizable amount (upto 40%) of<br>
&gt; time is spent in just this regular expression based parsing. Additionally<br>
&gt; since queries can return any kind of data, all of the data passed from<br>
&gt; virtuoso to Nepomuk has go through these checks.<br>
<br>
</div>Why use regular expressions to search for a fixed string? Simple string<br>
comparison would be much more efficient for that!<br></blockquote><div><br>My bad. We \
do not use regular expressions. We instead look through the entire query and try to \
pick up patterns by simple string comparisons.<br> <br>The relevant code can be found \
at nepomuk-core/services/storage/removeablemediamodel.cpp - convertFilexUrl and \
converFileUrls functions.<br> <br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Anders<br>
_______________________________________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" \
target="_blank">https://mail.kde.org/mailman/listinfo/nepomuk</a><br> \
</font></span></blockquote></div><br><br clear="all"><br>-- <br><span \
style="color:rgb(192,192,192)">Vishesh Handa</span><br><br> </div>



_______________________________________________
Nepomuk mailing list
Nepomuk@kde.org
https://mail.kde.org/mailman/listinfo/nepomuk


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic