Le dimanche 24 novembre 2013 19:42:25 Mark Gaiser a =E9crit :
> On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid <aacid@kde.org> wr=
ote:
> > In Okular we just got bug
> > https://bugs.kde.org/show_bug.cgi?id=3D327846
> > PDF Render time is unreasonably slow over cifs on high latency (WAN=
)
> > network connections
> >=20
> > Basically the issue is that poppler is quite read-intensive over fi=
les,
> > reading them over and over, and since the file is "local but really=

> > remote" it takes ages to render for big files.
> >=20
> > The only solution i can think of is doing a local copy and then wor=
king on
> > that.
>=20
> 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 use=
r
> manually copies the file and then opens it in a pdf reader: fine. Jus=
t
> 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=20
and trust the application to be smart and do whatever is most appropria=
te to=20
deliver the best result instead.
>=20
> > I saw KMountPoint::probablySlow that says
> >=20
> >     /**
> >    =20
> >      * Checks if the filesystem that is probably slow (nfs mounts).=

> >      * @return true if the filesystem is probably slow
> >      */
> >=20
> > And then returns true if the the filesystem type of the mount is nf=
s,
> > autofs or subfs.
> >=20
> > Any objection to replacing
> >=20
> >     /**
> >    =20
> >      * Checks if the filesystem that is probably slow (nfs mounts).=

> >      * @return true if the filesystem is probably slow
> >      */
> >=20
> > to
> >=20
> >     /**
> >    =20
> >      * Checks if the filesystem that is probably slow (network moun=
ts).
> >      * @return true if the filesystem is probably slow
> >      */
> >=20
> > and adding cifs to the list of mounttypes that are "probablySlow"?
>=20
> 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. Whateve=
r
> 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=20
ago for my home setup (so LAN only): NFS over a 100Mbit connection was =
almost=20
as fast as local access. Same NFS over a wifi connection capped at 3MBy=
tes.=20
That is much slower and can be worth adjusting the code path to take in=
to=20
account this difference.

> > Or anyone has a better suggestion to fix this issue?
>=20
> 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 ar=
e
> in place and if they are not there, how to implement them.

Would be nice, but sounds difficult to do reliably, especially without=20=

generating too much traffic.

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

Aur=E9lien