"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 f
 iles
(< 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
suggesting them to copy the file to his local drive?

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 saw KMountPoint::probablySlow that says

/**

* Checks if the filesystem that is probably slow (nfs mounts).
* @return true if the filesystem is probab
 ly
slow
*/

And then returns true if the the filesystem type of the mount is nfs,
autofs or subfs.

Any objection to replacing

/**

* Checks if the filesystem that is probably slow (nfs mounts).
* @return true if the filesystem is probably slow
*/

to

/**

* Checks if the filesystem that is probably slow (network mounts).
* @return true if the filesystem is probably slow
*/

and adding cifs to the list of mounttypes that are "probablySlow"?

It's not my place to object since the code isn't mine. Yet i do
disagree. Everything becomes slow if you mount it over a WAN. Whatever
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.

Or anyone has a better suggestion to fix this issue?

What should be done is detecting is the target is mounted via a slow
connection. So if it's mounted via the internet then "probablySlow"
should return true. On the other hand, i don't know if such checks are
in place and if they are not there, how to implement them.

Would be nice, but sounds difficult to do reliably, especially with
 out 
generating too much traffic.

I think all network-based file systems should be handled the same when it 
comes to the "probablySlow()" method: even if their performances vary, they 
will all perform worse than a local filesystem when the network they operate 
on is not at least a 100Mbit wired LAN connection. Of course exceptions exist: 
people do use wired connections, but since it is complicated to detect this, 
we need to optimize for the most common case. I think it is safe to assume 
that with tablets and laptops (some of them without ethernet ports) becoming 
more and more common, we have more and more people going wireless, so it's 
better to assume all network-based fs to be slow.

Aurélien