Opened 4 weeks ago

Last modified 15 hours ago

#377 new defect

1_41_RC4 is incredibly slow reading PDFs over network

Reported by: darcio Owned by:
Priority: major Milestone: 1.4.1
Component: Plugin: PDF Version: 1.4.0
Keywords: Cc:

Description

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.

Attachments (2)

lucide_dll_list (106.7 KB) - added by darcio 3 weeks ago.
dynamic DLL load for local storage PDF file
lucide_dll_list_NAS (118.5 KB) - added by darcio 3 weeks ago.
dynamic DLL load for NAS storage PDF file

Download all attachments as: .zip

Change History (9)

comment:1 Changed 3 weeks ago by diver

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

comment:2 Changed 3 weeks ago by 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.

comment:3 Changed 3 weeks ago by gyoung

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.

Last edited 3 weeks ago by gyoung (previous) (diff)

comment:4 Changed 3 weeks ago by 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.

comment:5 Changed 3 weeks ago by gyoung

@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.

comment:6 Changed 3 weeks ago by 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.

Changed 3 weeks ago by darcio

dynamic DLL load for local storage PDF file

Changed 3 weeks ago by darcio

dynamic DLL load for NAS storage PDF file

comment:7 Changed 15 hours ago by 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.

Note: See TracTickets for help on using tickets.