DynaPDFMBS Major Slowdown

I recently had to update MBS plugins to handle an issue with File opening.
Now, generating a PDF file using existing code , is taking 3 or 4 times longer than it used to do.
What used to take 30 seconds (big PDF) is now being reported to take up to 10 minutes on some users machines
I’ve swapped current code with code I was using 6 months ago, no change, so Im sure the slowdown is in the libraries themselves.

Has anyone else noticed this?

Beta 21.6r3 mentions a change that may be relevant:

Fixed a problem in Graphics class with DynaPDFMBS where in some case the font was not set and DynaPDF reported an error about missing font.

Im using 22.x at the moment, but updated from a version from around 2018

You can reproduce the issue (with smaller work load) on your machine?

Is that with using PageGraphics?

I have not had time to create a new small project : i have spent 5 days trying to understand where the slowdown is in the existing code and trying to compare ‘this year’ with ‘last year’

I don’t have several machines with different plugin levels to swap between.
So I’m firstly curious to know if anyone else has seen such a slowdown.

I am using PDF and DynaPDFGraphics classes.

I have recently introduced PDF.Pagegraphics in order that I can potentially make use of .drawobject (it was missing from DynapdfGraphics class - has it been updated?), but in my tests the line of code that would reference Pagegraphics is not yet being called.
I havent tried commenting it out yet.

Are you using fonts in the PDF? I had a massive slowdown with DynaPDF relating to massive font lists. You can experience the problem in Task Timer if you have it. I never got a resolution.

Well, for me it is difficult to debug since I only have you telling me about a potential issue.
I would need to know where exactly and make sure it’s not in your code.

If you can run this one a Mac, you could use Sample command in Activity monitor to analyze your running app and check in what functions it spends time.

The cited change should make sure that the plugin not just sets font when you change a property in graphics class, but also set it when there is no font yet set.

Typically I use I use Arial for headers, footers and a grid layout
plus possibly a symbol font and courier, swapping back and forth between them.

When not using the symbol font, I use Arial for headers, footers and a grid layout.
And many small bitmaps.

Apologies - I should have mentioned: there seems to be no similar slowdown on a Mac.
I appreciate you will struggle to debug unless I can assemble a small project somehow.
But right now, all I want to know is : does anyone else have the same experience?

When I can set up a machine with older plugins for comparison, I can establish some hard stats.
And assemble some representative code for a ‘small’ project.

(But bear in mind , mine are big and complex PDFs.
A small increase in any routine can have a very amplified effect if used 10000 times)

Menu/Project/Profile Code is good to see the used time.

or i would add a stop watch class to find the method which waste the time.

have you compared also project/build settings from older version?

is now being reported to take up to 10 minutes on some users machines

this days there was also a windows update … once again

take the same report (.pdf) now the same long time?

Yes. Windows is not updating.

In a test of the compiled app, using same source code, same document, and same output settings for the PDF:

using DLLs with version _19646.dll took 30 seconds to complete
using DLLs from version 22.x took 61 seconds to complete.

I’m convinced it’s something in the plugins, but I need to narrow down whether it is some specific call that is slower.
Maybe it’s a consequence of new code to handle API2. (Which I am not using)

Great. I’d be happy to hear details.

DynaPDFMBS has a TraceFile property to log calls. So we could see what you do.

Does that work on a compiled app?

yes, of course.
It’s for debugging in built apps.

Then I will email you directly.

I can report that if I replace only the DynaPDF plugin with the version from 2018, the speed improves again.
But I would lose the ability to .drawobject as I have been using the DynaPDFGraphics class from before PageGraphics was implemented

could you just comment out your drawobject calls?

I haven’t started using .drawobject in real code yet.
My testing so far is all code that doesn’t use pagegraphics or call .drawobject

So if anyone uses InsertPicture with a lot of repeating pictures, please note that each time you do that, the picture is encoded, passed to DynaPDF, then probably recompressed and stored.

if you repeat the pictures because you place the same ones all over pages, please encode them as e.g. JPEG yourself once. Then pass them to InsertImageFromBuffer. If you set JPEG to pass through with SetSaveNewImageFormat(False), you may get fastest time and smaller PDF since duplicates may get detected properly and replaced with references to first copy.

Thanks for tracking this down Christian.
It seems like a likely cause.
The DynaPDF plugin from 2018 does this consolidating of duplicates automatically.
The more recent changes for PNG are probably useful, and when done one image per PDF, will make no practical difference to speed of PDF creation.

It’s a classic instance of the effects of scale.
Going from perhaps one microsecond to two microseconds is imperceptible when one action is taken, but it takes twice as long.
In my case, this function has to be used thousands of times in one PDF, and it all mounts up.

It’s not the PNG thing.

More like the InsertPicture function has a switch and if the picture has alpha channel, we go by asking Xojo for PNG and pass that to DynaPDF.
At least that fixed a couple of bugs people had…

If you can make a JPEG, PNG, TIFF or BMP of the images you like to insert, that is always better. Especially if InsertFromBuffer can detect the new picture has same buffer and then reuse the already encoded one and save a lot of processing time.

1 Like