[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KMountPoint::probablySlow and cifs mount points
From: henry miller <hank () millerfarm ! com>
Date: 2013-11-25 12:33:51
Message-ID: fcff8427-6801-4334-ac06-1affd22ce44c () email ! android ! com
[Download RAW message or body]
"Aurélien Gâteau" <agateau@kde.org> wrote:
> Le dimanche 24 novembre 2013 19:42:25 Mark Gaiser a écrit :
> > On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid <aacid@kde.org>
> wrote:
> > > In Okular we just got bug
> > > https://bugs.kde.org/show_bug.cgi?id=327846
> > > PDF Render time is unreasonably slow over cifs on high latency
> (WAN)
> > > network connections
> > >
> > > Basically the issue is that poppler is quite read-intensive over
> files,
> > > reading them over and over, and since the file is "local but really
> > > remote" it takes ages to render for big files.
> > >
> > > The only solution i can think of is doing a local copy and then
> working on
> > > that.
> >
> > That would work with small files (< 10 MB) but will get you into
> > trouble for bigger files.
> > You can't - or shouldn't - do that in an automated manner. If the
> user
> > manually copies the file and then opens it in a pdf reader: fine.
> Just
> > don't auto copy the file. So you can probably give the user a popup
> I disagree with that: I believe the use should not have to worry about
> this
> and trust the application to be smart and do whatever is most
> appropriate to
> deliver the best result instead.
I agree, with the note that if there isn't 'significantly' more disk space \
locally than the file size the right thing is don't copy locally. \
Hopefully not a problems for pdfs though
> >
> > it is. It also depends on your internet connection and where you're
> > connecting to. Saying smb, nfs or cifs is slow - per se - is plain
> > wrong. All of those are "likely" fast if you mount them locally.
>
> It really depends on the definition of "fast". I made measurements some
> time
> ago for my home setup (so LAN only): NFS over a 100Mbit connection was
> almost
> as fast as local access. Same NFS over a wifi connection capped at
> 3MBytes.
> That is much slower and can be worth adjusting the code path to take
> into
> account this difference.
If you have the right RAID setup on a NAS box connected with gigabit \
ethernet, the network drives can even be faster than the local ones. This \
is becoming common in offices which is one target of okular
>
> > > Or anyone has a better suggestion to fix this issue?
I just had a complex, and perhaps crazy idea: check the times for the first \
few reads, if they come back as the remote file is 'slow', do a local copy. \
Okaular might be able to get away with reading all the data for the first \
page, rendering that, and then starting the local copy if reading took too \
long.
It seems to me that anything else is optimizing for one set of users at the \
expense of the other. On the otherhand, tablets on wifi (or less) is \
probably hurt more by the wrong optimzation than office users, and the code \
is much simpler.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
[Attachment #3 (text/html)]
<html><head></head><body><br><br><div class="gmail_quote">"Aurélien \
Gâteau" <agateau@kde.org> wrote:<blockquote class="gmail_quote" \
style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, \
204); padding-left: 1ex;"> <pre class="k9mail">Le dimanche 24 novembre 2013 \
19:42:25 Mark Gaiser a écrit :<br /><blockquote class="gmail_quote" \
style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; \
padding-left: 1ex;">On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid \
<aacid@kde.org> wrote:<br /><blockquote class="gmail_quote" \
style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; \
padding-left: 1ex;">In Okular we just got bug<br /><a \
href="https://bugs.kde.org/show_bug.cgi?id=327846">https://bugs.kde.org/show_bug.cgi?id=327846</a><br \
/>PDF Render time is unreasonably slow over cifs on high latency (WAN)<br \
/>network connections<br /><br />Basically the issue is that poppler is \
quite read-intensive over files,<br />reading them over and over, and since \
the file is "local but really<br />remote" it takes ages to render for big \
files.<br /><br />The only solution i can think of is doing a local copy \
and then working on<br />that.</blockquote><br />That would work with small \
f iles
(< 10 MB) but will get you into<br />trouble for bigger files.<br />You \
can't - or shouldn't - do that in an automated manner. If the user<br \
/>manually copies the file and then opens it in a pdf reader: fine. Just<br \
/>don't auto copy the file. So you can probably give the user a popup<br \
/>suggesting them to copy the file to his local drive?</blockquote><br />I \
disagree with that: I believe the use should not have to worry about this \
<br />and trust the application to be smart and do whatever is most \
appropriate to <br />deliver the best result instead.<br /><br \
/><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; \
border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote \
class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px \
solid #ad7fa8; padding-left: 1ex;">I saw KMountPoint::probablySlow that \
says<br /><br />/**<br /><br />* Checks if the filesystem that is probably \
slow (nfs mounts).<br />* @return true if the filesystem is probab ly
slow<br />*/<br /><br />And then returns true if the the filesystem type of \
the mount is nfs,<br />autofs or subfs.<br /><br />Any objection to \
replacing<br /><br />/**<br /><br />* Checks if the filesystem that is \
probably slow (nfs mounts).<br />* @return true if the filesystem is \
probably slow<br />*/<br /><br />to<br /><br />/**<br /><br />* Checks if \
the filesystem that is probably slow (network mounts).<br />* @return true \
if the filesystem is probably slow<br />*/<br /><br />and adding cifs to \
the list of mounttypes that are "probablySlow"?</blockquote><br />It's not \
my place to object since the code isn't mine. Yet i do<br />disagree. \
Everything becomes slow if you mount it over a WAN. Whatever<br />it is. It \
also depends on your internet connection and where you're<br />connecting \
to. Saying smb, nfs or cifs is slow - per se - is plain<br />wrong. All of \
those are "likely" fast if you mount them locally.</blockquote><br />It \
really depends on the definition of "fast"
. I
made measurements some time <br />ago for my home setup (so LAN only): NFS \
over a 100Mbit connection was almost <br />as fast as local access. Same \
NFS over a wifi connection capped at 3MBytes. <br />That is much slower and \
can be worth adjusting the code path to take into <br />account this \
difference.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt \
0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: \
1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; \
border-left: 1px solid #ad7fa8; padding-left: 1ex;">Or anyone has a better \
suggestion to fix this issue?</blockquote><br />What should be done is \
detecting is the target is mounted via a slow<br />connection. So if it's \
mounted via the internet then "probablySlow"<br />should return true. On \
the other hand, i don't know if such checks are<br />in place and if they \
are not there, how to implement them.</blockquote><br />Would be nice, but \
sounds difficult to do reliably, especially with out <br
/>generating too much traffic.<br /><br />I think all network-based file \
systems should be handled the same when it <br />comes to the \
"probablySlow()" method: even if their performances vary, they <br />will \
all perform worse than a local filesystem when the network they operate <br \
/>on is not at least a 100Mbit wired LAN connection. Of course exceptions \
exist: <br />people do use wired connections, but since it is complicated \
to detect this, <br />we need to optimize for the most common case. I think \
it is safe to assume <br />that with tablets and laptops (some of them \
without ethernet ports) becoming <br />more and more common, we have more \
and more people going wireless, so it's <br />better to assume all \
network-based fs to be slow.<br /><br />Aurélien<br \
/></pre></blockquote></div><br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my \
brevity.</body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic