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