[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