batch export - reduce loading time

[Johanna_M]

Hello!

Is it possible to shorten the loading time when switching to batch export?
We currently have around 50 actions in a batch command in a project. The loading time is around 10 to 15 seconds each time. We also have the same problem in other projects.

Thank you in advance for your support!

Kind regards,
Johanna

[Tim Green]

Hi Johanna,

Is it possible to shorten the loading time when switching to batch export?

I'm not entirely sure what you mean here. Are you referring to switching from the regular Publish page to the Publishing Task Manager? That shouldn't generally have a delay. However, judging by the number of build options shown in your other posting it might be more efficient for you to create normal build scripts using the command line build interface rather than using the Publishing Task Manager for this. Then you can initiate your entire build process just by starting the batch file.

See this chapter in the documentation for details of the command line build interface:

https://www.helpandmanual.com/help/hm_a ... dline.html

[Johanna_M]

Hi Tim,

you are right, this is the same project with many build-options and many export commands.
The problem is, i need to check the created PDF-document and adjust the page breaks. After every change in the project, I have to create the PDF again.
And everytime I switch from the working space to the export commands I have to wait about 10-15 seconds.

Please see the attached gif.Do not wonder, the GIF does not hang, that is the long loading time of H+M.

I would be really happy if you could find a solution.
But I can also understand if that doesn't work. Thank you in advance anyway!

Kind regards,
Johanna

[Tim Green]

Hi Johanna,

The long switch is probably related to the excessive number of build options you have defined. Help+Manual needs to poll these to be able to display them in the Publish screen. Other reasons for slow performance are:

* Trying to run Help+Manual over a network or VPN connection
* Trying to edit projects over a VPN or other Internet connection
* User configuration problems causing slow startup
* Orphaned network references to your project referencing locations on the network that no longer exist.
* Network performance if you are storing large projects on a network drive/share and working there
* Use of a large number of embedded images in your project.
* Use of a large number of linked snippers in your project, particularly when they are accessed via a network
* Integration of your project in a Subversion repository incorrectly using network locations for the working copies of your project.

** Trying to run Help+Manual over a network or VPN connection

Storing Help+Manual on a network drive and starting it from there will always be slower than a local installation. If you are running the Server version of Help+Manual 7 or earlier this can't be avoided, but versions 8 and above no longer need to do this with the new Floating licenses. You should NEVER try to run Help+Manual over a VPN or other Internet connection. They are not reliable or fast enough for this and you will get both terrible performance and data corruption (sooner or later, probably sooner). If you need to work remotely, use version control so that you can work on a synchronized local working copy. If that is not possible, use Remote Desktop to log into a remote Help+Manual installation that is on the same computer as the project being edited. This will still be slower, but it is at least reliable.

** Trying to edit projects over a VPN or other Internet connection

Here too, just don't do it. No Internet connection is fast or reliable enough to edit a project across it, and you will get terrible performance and most likely also data corruption. Use version control or Remote Desktop.

** User configuration problems causing slow startup

The most common cause of slow startup is the Recent Projects list in the Open menu. If projects there are on unavailable locations, Windows takes a long time checking them. Right-click on any unavailable projects there and remove them from the list.

If that doesn't help, you can try resetting all your user settings. You will need your license key for this. In the Windows Start menu select Run and enter "regedit" to start the Registry Editor. Go to HKEY_CURRENT_USER > Software > ECSOFTWARE. Select the Help+Manual X key (folder), where X is your major version number, then right-click and select EXPORT to export it to a file. Then delete it completely and restart H+M twice -- once to re-generate the registry settings and enter your license key, and then again to see the normal start behavior.

If it's faster, the problem was in the settings. If it still starts slowly with fresh settings, then it is probably being slowed down by Windows Defender or a third-party anti-virus program. Disabling it for a test would be the first method in that case.

** Orphaned network references

Slow loading and saving performance is often caused by orphaned network references in your project to locations on the network that no longer exist, and it may be made worse by embedded images in your project, which can also slow down editing. This can apply in particular to image file references if the Project Search Path contains orphaned network references.

Windows networks take a very long time to resolve invalid network references. In your project go to the following locations and delete any references to network locations that are no longer valid:

Project Explorer > Configuration > Common Properties > Project Search Path
Project Explorer > Configuration > Common Properties > Help Windows: HTML Help Options
File > Recent projects (delete any projects shown in red that no longer exist)

** Network performance

If you are storing your projects on a network drive or share it is possible that the network itself may be the bottleneck. To test this, try making a copy of your project on your local machine and edit it there for a while to see if you get better performance. Use Save As... in the Help & Manual File menu to save the copy, and save it in a folder in your own Documents directory on your local computer. Using the Documents directory ensures that you won't have Windows account permissions problems, because you always have full read and write permissions there.

** Embedded images

When you copy and paste images from another program like Word they are initially embedded in your project. If you have more than just a couple of these images they can inflate the size of your project and will eventually slow down editing because embedded images use up very large amounts of memory and computer resources (many times their own uncompressed size). You need to convert embedded images to external files:

1. Click on an image in the Help & Manual editor. If it turns "negative" when you select it, it is OK. If it does not, it is embedded.
2. Right-click on the embedded image and select the option to convert it to an external file.
3. Repeat this for all embedded images in your project.

You can also locate embedded images with the Project Report tool in the Project tab. Run a full report with image references and search for the word "embedded" in the report. That will show you which topics contain embedded images.

** Linked snippets

Linked snippets use a fair amount of resources, particularly if they are stored on network drives. If you have a lot of them it can slow down project management. This has been improved as far as possible in the current version of Help+Manual 9, but it still has an influence.

** Version control working copy on a network drive

Version control works very differently from normal multi-user editing. In normal multi-user, everyone works on the same copy of the project on a network drive accessed by all users. You cannot and should not use this paradigm with version control (Subversion or Team Foundation Server), and if you do you will experience performance degradation and other issues. You will also get a serious degradation of performance if each user tries to put their version control working copy of the project on a network drive instead of locally.

When working with version control, every user must work on their own local, linked copy of the project. This copy must be stored on a local drive on the computer they are working on, NOT on a network drive. This is crucial for version control to work properly.

You can find full instructions for setting up version control correctly in this chapter in the HM help:

https://www.helpandmanual.com/help/hm_advanced_vcs.html