<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 files
(< 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 probably
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 without <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>