Saving PDF takes 10 minutes, CPU pegged

[marilynd]

I have a moderately sized WebHelp project, and I just tried generating PDF for it using v4.0. It eventually completed, but I had my doubts, as it took 10 minutes to save the PDF file, and the CPU was pegged by the Flare.exe process all during this time. The first time I tried to generate PDF I gave up after 5 or 6 minutes and killed the process, thinking it was in an infinite loop. So what's up with saving PDF to a file taking so long? Is there some way to speed this up, or at least show progress during this time? FWIW, the final PDF file is 12MB.

Thanks,
Marilyn

[LTinker68]

I think it's because there is a lot of setup that needs to be done behind the scenes in order to build a single PDF file. If you think about it, for WebHelp output, if you have a masterpage then Flare applies that masterpage to each topic one at a time. And the TOC in WebHelp is basically just hyperlinks, so it's dynamic. But when Flare builds PDF, it has to look at the TOC, apply the appropriate page of the appropriate page layout to the appropriate topic, create the link in the TOC to that topic and figure out what its page number will be, resolve all "see page x" cross references, build the index pointing to the right page for that topic (or write the info to a temporary file), and so on and so on. It has to do that for every topic then build everything into the single file. It might actually be appending the PDF as it goes, but it's still a lot more processing that has to be done because it's not a dynamic medium like online output is.

In my case, I have half a dozen page layouts, and just as applying masterpages to WebHelp output slows its build-time down, so page layouts (especially multiple page layouts) slow down the PDF build.

I'm up to about 8 minutes although I don't know how many topics I have at the moment. If I need to check a single topic or a single chapter then I have a "testPDF" target and TOC and I add the topics to that test TOC and build it. Since it's just a topic or two or three it builds much faster.

[marilynd]

Thanks for the explanation, Lisa. The Messages window in Flare does update as the build is progressing through the various pages, so during that time I know what's happening. The mysterious 10 minute CPU-intensive silent wait happens during the "Saving PDF" message. Since the CPU is pegged, I can't do much of anything on my computer during this time (e.g. Outlook hangs). It might be helpful to have the message say "Saving PDF (this may take several minutes)..."

[doc_guy]

I've found that this delay time varies GREATLY depending on the hardware you are running. I have built the same PDF target on 3 separate machines simultaneously to see how they compare. On my oldest machine with the least amount of RAM (1GB), the PDF build took 25+ minutes. On my middle-aged machine with 2GB of RAM, the PDF build took about 13 minutes. On my new machine with 4GB of RAM, the PDF build took less than 3 minutes. The final output was about 200 pages.

Building the PDF is apparently a processor/RAM intensive activity. The more resources you can devote to it, the faster it will go. This is absolutely a case for you to upgrade the RAM in your computer. If you can save 10 minutes every time you build your project, and if you are building twice a day, then you are saving 100 minutes a week, or 400 minutes a month -- that is over 6 and a half hours. Suppose you make 15 dollars an hour (hopefully a conservative guess): that is $100 bucks spent sitting around doing nothing for the month. Over a year, and you are wasting $1200 waiting for your project to build. Now figure out how much the RAM upgrade will cost, and make your case from there.

I don't know how much you make per hour, but when I start talking to my boss about how much time it costs me to sit waiting for the project to build, and how much it is costing the company, it becomes clear quickly that it is worth spending some money on hardware to make me more productive.

EDIT: the middle paragraph for clarity and grammar

[marilynd]

Thanks for the different test results. The numbers fit perfectly with what I'm seeing: I have 2GM RAM and the PDF output is just under 200 pages. I can use your data in planning my work day and timing the next hardware upgrade.

[doc_guy]

Hope it helps. Hope you can get a hardware upgrade sometime soon, because once I saw it build on my newest laptop (personal, not work), it is really hard to want to do it on my work laptop anymore!

[DocuWil]

I noticed the same things a while ago and reported everything to Technical Support.
I hoped everything would have been improved with the latest release (4.1.19), but nothing changed so far.

To test some things you can create a new project based on the Sample book from Madcap.

Since the time I noticed this behaviour (incl. the Bookmark sector behind the Index!), I created a Word output with PDF. That's 80% quicker and the size of the PDF will be about 90% smaller.
However, since the 4.1.19 version my Word output is really bad. Something is completely wrong with the TOC and content that wasn't before. I am investigating this problem now.
So, maybe I have to roll back to the previous version.

[doc_guy]

The PDF size coming directly from Flare is an issue.

I end up opening my PDFs in Acrobat (not Reader), and re-saving them using the "Reduce File Size" option. This brings down the file size dramatically. (I'd say 75% or greater file reduction.)

[DocuWil]

And ...... at the same time deleting the Bookmark section below the Index.
Thanks for the good tip DocGuy. I didn't think of that (tunnelvision?).

[KevinDAmery]

The PDF size coming directly from Flare is an issue.

I end up opening my PDFs in Acrobat (not Reader), and re-saving them using the "Reduce File Size" option. This brings down the file size dramatically. (I'd say 75% or greater file reduction.)

Of course, they really should expose those tools in Flare's PDF target so we don't have to do the two step. I've already submitted a request on it, but as always the more the merrier....