From kde-core-devel Sun Nov 24 23:12:34 2013 From: Albert Astals Cid Date: Sun, 24 Nov 2013 23:12:34 +0000 To: kde-core-devel Subject: Re: KMountPoint::probablySlow and cifs mount points Message-Id: <8661419.kYXyB3qsOU () xps> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=138533477131383 El Dilluns, 25 de novembre de 2013, a les 00:01:41, Mark Gaiser va escriure: > On Sun, Nov 24, 2013 at 10:09 PM, Albert Astals Cid wrote: > > El Diumenge, 24 de novembre de 2013, a les 19:42:25, Mark Gaiser va escriure: > >> On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid 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. > > > > Why? > > See my example below. > > >> 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? > > > > Why? If you open a huge file by smb:// it'll copy it to the local file > > anyway, so why should not we copy it? > > Right. True but should it be like that? > Lets take playing a movie from smb as an example. If you do that now > in for example mplayer then kde will simply copy the movie to your > local drive and start playing it. But should that be the case? I > consider it a massive usability bug. One that isn't easy to fix. If > you would mount the same share as cifs then the system "thinks" it's > local and just plays the movie without copying. > > That is how it should be. Copying to your local system is a nasty > workaround which should imho be prevented. A PDF file is not a movie, it can't be read lineraly. > > This is especially a big issue when you want to watch a movie of - > lets say - 10GB in size. I have that very often and it sucks that it's > being copied. So i find myself mounting that network drive when i want > to see something since that is both faster and prevents needless > copies. > > >> > I saw KMountPoint::probablySlow that says > >> > > >> > /** > >> > > >> > * Checks if the filesystem that is probably slow (nfs mounts). > >> > * @return true if the filesystem is probably 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. > > > > That's why it's called "probablySlow", no? > > It's probably slow if you use a slow connection. It's "probablyFast" > if you just use it as in internal network. Not over the internet. And > i think you should assume that most people mount those drives through > an internal network. The exception is mounting through the internet. > > >> > 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. > > > > How are you going to define "slow connection"? > > Ping and measure latency? Or use networkmanager to discover if a > connection is made through a line that is also having the internet > connection? If so then the connection is made via internet thus > "probablySlow". > > I don't know if those ideas are possible, but is sounds plausible. How much is that going to take? is it going to add a 100ms delay to every single file you open in Okular so that it can send a few pings and see if they come back fast or slow? Cheers, Albert > > > Cheers, > > > > Albert > > > >> > Cheers, > >> > > >> > Albert > >> > >> Just my 5 cents.