What could cause slow WebHelp builds?

[amatsumoto]

I've got a help project that has recently become very slow to build in WebHelp. I'm using Flare 3.1. The project isn't a large one and it used to take about 20 minutes to build. In the past two weeks or so, the time to complete a build has gone up tremendously, taking closer to 2 hours. The output seems to be fine. Not much has changed in the project really, other that adding maybe a dozen new topics and adding more hyperlinks. Some of the new topics use conditional text.

If I the build for FrameMaker, it doesn't seem to take any longer than it used to, so I'm trying to figure out what could be affecting the speed for WebHelp.

What should I be looking for or considering?

[RamonS]

The more obvious reasons would be fragmented file system, real-time virus scan, building to a network share. What you can also try is deleting everything in the output folder and try again (which could take 2 hours if that doesn't do the trick).
Can you share any information about the environment, such as OS, where the build goes, etc.

[amatsumoto]

There are three of us who work on this help project and we all use Windows XP. The Help project is located on a network drive, and the output goes to a subdirectory under the project directory. We created this project about a month ago.

The project (I'll call it Project A) is a compilation of topic files plus another small project file (Project B) that is merged into the WebHelp TOC of Project A. The organization has always been like this, so it didn't seem like having Project B merged into Project A would be a problem (it was much faster when we first created the project). I tried removing the Project B from the Project A WebHelp TOC and compiled WebHelp to see if this was causing the slowness. It still took an unusually long time. I also tried generating an independent WebHelp build for Project B and it turns out that it also takes approximately 3 times longer to build than it used to.

[RamonS]

How long does it take when you build locally? Did anything change in regards to the network share?

[LTinker68]

Has your company also deployed virus scan software throughout your organization? If they've also deployed it to the networked share, then that server may be scanning the files as they're added to the server and that could be slowing it down, too.

[Richard Ferrell]

Move the project to a local machine to compare build times,

[wclass]

I have noticed that adding a master page can double the compile time - have you changed this sort of thing recently?

[Adrian Durand]

Hi,

I have my project on a local drive, and have approx 1100 topics (including a Master Page).
The last build I did in V3.1 took approx 7.5 minutes, BUT, after upgrading to V4, the build only took 2.5 minutes.

If you have V4 installed, try carrying out a build (ensuring a copy of the project is taken first) and see if this is any quicker.

Regards

Adrian

[NorthEast]

I've also noticed a speed increase in v4, from 17mins down to 10mins for a 1600 topic WebHelp project. Great!

Master pages do slow things down, which is expected if they include breadcrumbs, miniTocs, etc.

[KevinDAmery]

I agree with Richard. Keep the source on the network drive, but when you need to do a build copy it locally, build to your local drive, then copy the output back to the network. In my experience this saves an enormous amount of time even after taking the copy times into account.

[Richard Ferrell]

Masterpage and Pagelayouts do slow down a build, as it has to be applied to every file, But V4 does build a lot quicker than Flare v3.1 I have seen build times get cut in half in Flare v4.

[amatsumoto]

Thanks for all your responses and suggestions. I moved a copy of the project to my local drive and it is still processing the output. It's almost at 40 minutes processing time and it's nowhere near finished. I deleted all previous output before I started.

What surprises me is to hear that a project with 1100 topics generated by v3.1 took a little over 7 minutes to build, even with a master page. Our project includes a master page and only 173 topics, and the build on the the network yesterday took 2 hours and 55 minutes! Since the local build is still going and it's been more than 40 minutes, I'm not feeling confident that it will do much better. Even if it does take less time, it sounds disproportionately slow compared to what the rest of you have said.

I feel like something is really wrong, and I'm wondering if it would be worth my while to create a new project and copy the existing content files into the new project? Could the problem be with the project file, or with the content files themselves?

Thanks

[RamonS]

Before you go through that much trouble I'd get in contact with MadCap support and send them the project over. If there is indeed something wrong with the project itself it should tie up their boxes the same way as it does your's.

[amatsumoto]

As it turns out, the problem was an apparently corrupt master page. This is the second time I've run into a bizarre build problem that was caused by the master page.

I decided to see how fast help would compile if I didn't use a master page. On my local drive, it took 1 min. 19 sec. (versus 1 hour 40 min. to compile locally with a master page). Then I copied a "clean" version of my master page from elsewhere into the local project and compiled. It took 4 min. and 12 sec. to build. Finally, I copied the same "clean" master page to the full version of the original project on the network (it includes the merged project) and compiled. That build took 14 min. 12 sec. (versus the 2 hours 55 min. from yesterday). I'm sure it would take even less time to build if I generated the files locally.

My new build troubleshooting mantra is going to be "First check the master page!"

Thanks everyone,

[KevinDAmery]

Add to that "save early, save often, make backups" Having a clean master page to fall back to seems to have saved you a lot of trouble in this case.

[RamonS]

And that is what will be available when using source control. As I pointed out before, when you treat help projects the same way as application code good things will happen.

[Richard Ferrell]

With Source Control Programs you want to make sure that it treats the Flare files as Binary and not Text, there are some SC progrmas that will make changes to text files, and this can cause the corruption.

[KevinDAmery]

And that is what will be available when using source control. As I pointed out before, when you treat help projects the same way as application code good things will happen.

To a point. It still requires you to save and check in when you have a "good" version. In multiple writer shops this shouldn't be much of a problem (other writers calling your extension to complain that you have the lock on the file they need tends to cure you of bad habits) but for lone writers there's a tendency to get lazy and leave the doc source files checked out all the time.

But that problem isn't in Flare's code, it's between the keyboard and the seat

[RamonS]

That's why I say. treat it like application code. No developer in the right mind would not make at least daily copies at least....although I met those developers. One hard drive crash later all the work they did the past three years is gone.

[KevinDAmery]

Same here - I worked with a developer once who always checked out all the code he needed for his features, made a local copy, then undid the check out. He'd work on his local copy for weeks until he was ready to integrate it, then check everything back in... and then wonder why his code didn't work with the main application and why the other developers went and changed things in other modules. (You know, by developing the features *they* were responsible for....)

Let's just say some of the developer meetings got a little loud