KMountPoint::probablySlow and cifs mount points

[henry miller]

"Aurélien Gâteau" <agateau at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20131125/818c23c1/attachment.htm>