Created attachment 183754 [details] Excerpt from Samba file server log file SUMMARY I have the same problem as in bug #327846 but I have no high latency WAN. The problem affects the LAN as well. The server has a 10 GBit/s uplink and the client is connected by 1 GBit/s. I'm on Debian Linux bookworm amd64: okular (4:22.12.3-1) Example: Opening a PDF file of 160 kB from a Samba share can take up to 10 seconds using Okular. While copying the remote file to a local folder runs in less than a second. And then Okular opens it instantly as well. So it's neither the bandwidth nor the PDF file. So the problem is the way Okular reads the file from the network share. I enabled verbose logging on my Samba file server. From the debug log file I can see that Okular seems to read only 256 bytes per Samba request. So even for a 160 kB file quite a lot of requests seem to be necessary. As I use krb5p (or at least krb5i) for the Samba mount, there is for sure some overhead. Is it possible to increase the read buffer from 256 bytes to something larger? Maybe 16384 bytes? Of, if RAM is not a problem on the client, Okular might cache the entire file in memory/RAM and then read/parse the PDF data in small chunks? My laptop has 32 GB of RAM. So I wouldn't mind if Okular would preload even 300 MB large PDF files to RAM and then examine/load them in-memory. I'm not sure if the place to fix this is Okular or a KDE PDF or Poppler library / component as I'm not familiar with the architecture of Okular or its PDF backend. STEPS TO REPRODUCE 1. Mount Samba share with krb5p 2. Open a 160 kB PDF file on such a share from Dolphin 3. Wait for Okular to open the file OBSERVED RESULT Takes 10 seconds to get ready. EXPECTED RESULT Opens instantly. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian 12 amd64 KDE Plasma Version: 4:5.27.5-2 KDE Frameworks Version: don't know / Debian bookworm stable Qt Version: libqt5core5a (5.15.8+dfsg-11+deb12u3) ADDITIONAL INFORMATION
Created attachment 183771 [details] Search results from gitlab.freedesktop.org See attachment 2025 [details]-08-04_poppler_buffer.png - might this be the critical thing? Any chance for Okular to have Poppler operate on an in-memory buffer instead of seeking in 256 byte portions over the Samba share?
MuPDF (https://packages.debian.org/bookworm/mupdf) - which is not based on Poppler, as far as I know - opens the same PDF file over the same Samba remote share instantly in fractions of a second! No delay! But it lacks so many features of Okular. :(
(In reply to Sebastian from comment #1) > Created attachment 183771 [details] > Search results from gitlab.freedesktop.org > > See attachment 2025 [details]-08-04_poppler_buffer.png - might this be the > critical thing? > > Any chance for Okular to have Poppler operate on an in-memory buffer instead > of seeking in 256 byte portions over the Samba share? Try change that constant in poppler to something fairly larger and see what happens ? I do think that working on 256 bytes increments might have been the right thing back in the days of floppy drives ... ?
First of all, I've filed a bug at Poppler: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1616 Even a command line tool like pdftoppm suffers from the same problem. Takes a minute when reading from Samba share and only a few seconds when reading from local disk. (In reply to Sune Vuorela from comment #3) > Try change that constant in poppler to something fairly larger and see what > happens ? Unfortunately, I don't really know how to build Okular with a custom Poppler library so that it doesn't use the libraries installed from the package repository. In Debian, Okular seems to depend on libpoppler-qt5-1 which depends on libpoppler126 and I guess the last one is the library I had to patch? (In reply to Sune Vuorela from comment #3) > I do think that working on 256 bytes increments might have been > the right thing back in the days of floppy drives ... ? I totally agree! Even for a local disk 256 bytes seem very small, given that HDD/SSD sectors nowadays are 4K / 4096 bytes at once. And it seems to be fatal for remote mounts with some latency.