1_41_RC4 is incredibly slow reading PDFs over network

[darcio]

I have the latest Lucide test version installed and as I attempted to move my locally stored documents to the LAN NAS box (ZyXel 325 V2) I discovered that attempting to view any PDFs stored on that NAS box is incredibly slow. Local storage is fast though.

I'm using NetDrive (3.1.6.876) here with the latest Samba client (samba-client.i686 - 4.9.5-1.oc00). Indeed, reading other files appears to move along pretty quickly, JPG images are fast, as are MP4 files. Only the PDFs appear to suffer.

I opened a thread on this topic here (​https://www.os2world.com/forum/index.php/topic,2034.0.html). Paul reviewed the samba client logs and ollowing some troubleshooting suggestions I discovered that Lucide 1.3.5 GA does not appear to suffer from the same problem.

Not sure what additional info/logs to provide at the moment to help troubleshoot further.

[Silvan Scherrer]

please try also with qpdfview to see if it's poppler or a lucide issue. as we did some tests and qpdfview was a lot faster over network than lucide. but YMMV

[herwigb]

Tried with Lucide 1.4.0 using popple66.dll and qpdfview with latest poppler, in addition with bitwise ndpsmb plugin 2.3.0 (based upon Samba 3.6.x). Neither setup shows any "incredible slowness".

qpdfview is faster than Lucide, however Lucide is workable normally.

[Gregg Young]

I just tried with the Lucide that hopefully will be 1.5.0 GA and don't see this. (Using the smb client 4.9.5 the server is 3.3.16 on OS2) The only changes from the 1.4.1 beta 4 are the addition of a Polish translation and fixing unhighlighting neither of which would effect this. Dariusz can you send me a file that shows this issue for you? Here Lucide is slightly faster than qpdfview but both are fully usable. 1.3.5 is slower than 1.5.0 also.

[darcio]

So guys, the poppler library installed here is: poppler.pentium4 - 0.59.0-3.oc00.

@diver Yes, QPDFView shows the same behaviour, identical throughput if you will, it is using the same poppler library as Lucide.

@gyoung I sent you an email with the PDF file, it's about 2.5Meg.

Per Gregg's suggestion I will try to find Beta2 of QPDFViewer to try it out first and will re-install Lucide RC4 and downlevel the poppler library.

[Gregg Young]

@Dariusz I got the pdf you sent. I tried it with Lucide 1.5.0, QPDFView 0.4.17 beta 2 and Ghostview. While Ghostview probably loaded the fastest the differences were negligible. The only meaningful difference I saw was the file open dialog in QPDFView took much longer to populate than the other 2.

QPDFView 0.4.17 beta 2 is in the netlabs-rel RPM repository.

You probably don't want to down level. The Poppler I am using 0.59.0-3 which is the latest. I have the i686 version installed. The difference between -2 and -3 is the deprecated internal jpg rendering engine is used for -2 and an external lib is used for jpg rendering in -3.

[darcio]

OK, so you are definitely seeing something different than I. Alright, sounds to me like something else on my machine is impacting this.

I ran through the dynamic DLL load of 'DLLTree', generated a report for a local PDF load as well as the NAS based load. There are some differences and to me they seem kind of weird, meaning: MMIO stuff is pulled in for the NAS read.

Take a look please at the load report, if you do a compare on these you'll find DLLs like: gifproc.dll, mmparts.dll, mmptmri.dll, os2oor3u.dll and others. Many come from the \mmos2\dll tree, others directly from the \os2\dll tree.

I have no idea why these would be invoked on a NAS load. In addition to this test I confirmed that I am seeing this slowness across multiple network storage locations (trying to exclude just my NAS box as the culprit) such as Win10 and Win7 shares.

One more comment re: actual speed. In the case of NAS PDF read I am seeing rates of 100-750 Kbytes, whereas something like GhostView will pull a file down at 2-5 Mbytes, this is consistent across all LAN devices. So on average I'm seeing a 10x difference in performance, which should not be the case.

[darcio]

dynamic DLL load for local storage PDF file

[darcio]

dynamic DLL load for NAS storage PDF file

[darcio]

Any ideas what other debugging approaches I could try to further troubleshoot this issue?

Given the loaded DLLs list I thought that maybe OpenDoc was getting pulled in somehow (see stuff like OS2OM30.DLL and OS2OOOC.DLL which are part of mmparts.dll file). But I checked my system and the old OpenDoc install I had on here (part of the VisualAge install I think?) is no longer present.

[Gregg Young]

A couple of things you can try. Update to libcn0.dll. The other thing would be to try with all the libs coming from the 686 repo instead of Pentium 4. I will diff the 2 dll lists and see if any of it seems relevant.

I will send you the first 1.5.1 build if you like. However, it requires libcn0.dll and libcx 0.6.5-1

Couple more questions. You said jpgs load quickly. Is that using Lucide? This issue is with files loading in Lucide not the populating of the file dialog correct? Does Lucide try to make thumbnails on loading? If so have you tried turning thumbnails off?

[darcio]

@gyoung I have libcn0.dll already installed, specifically I have the following:
libc.i686 1:0.1.1-1.oc00
libc-devel.i686 1:0.1.1-1.oc00
libcurl.pentium4 7.37.0-2.oc00
libcx.pentium4 0.6.5-1.oc00
libcx-devel.pentium4 0.6.5-1.oc00

I do not have thumbnails enabled, I disabled when I was attempting to debug the slow-load issue.

The JPEG view through Lucide is FAST...so typically I see a 5-6 Meg throughput as opposed to the 400k with PDFs. It matches the rates I'm seeing with using PMView directly.

[darcio]

...ahhh, sorry missed a couple more questions:

1) load time - only applicable to actual loading of PDFs, I am not seeing this with File Dialog population
2) 1.5.1 - sure thing, fire away, happy to test, the pre-req DLLs are already on my machine I believe