FM 2019 - Open/save files is very slow

[Russ Ward]

Hi, I have finally started to seriously test out 64-bit  FM2019, evaluating whether to migrate from FM2015. I find that it takes almost 3 times longer to open and save files, which is prohibitively slow. The files are either structured binaries or XML with a custom application. All files and references are local. Computer details:

Dell Latitude laptop

Windows 10, 64-bit

Processor - Intel Core i7-7600U CPU @ 2.80 GHz

RAM - 16 Gb

I am running the comparisons with FM2015 installed on the same computer. Does anyone have any thoughts? Is the computer underpowered? FM2019 seems to be working well and I like some of the new features, but I will stay with FM2015 if it means I can open a 100 page file in 6 seconds instead of 15.

Thanks,

Russ

[Stefan Gentz · Accepted solution]

Hi Russ,

all these tasks should be 10 to 20% faster in FM 2019 64 bit than in FM 2015.

Have you tested your files on a “clean” FM install? Or with custom plugins?

Can you share some files for testing with us?

Thanks,

Stefan

[Russ Ward]

Hi Stefan,

I think it may be a plugin, of which I have many. This was an obvious culprit... I am a bit embarrassed that I did not suspect that myself. Let me take a little time to see what is holding things up. I'll get back in a bit.

Russ

[Russ Ward]

OK, the delay occurs while one of my plugins is processing. I don't know the exact cause of the slowdown, but certainly it is a plugin, so thank you Stefan for the clue.

Upon a structured document save or open, the plugin goes through and sets all element attribute displays to "populated and required" only, for example:

F_ApiSetInt(docId, elemId, FP_AttrDisplay, FV_ATTR_DISP_REQSPEC);

The operation is generally very fast in FM2015. I don't know what might have changed, but the routine runs much slower in FM2019.

Russ

[Russ Ward]

In case anyone else happens to bump into this issue, I solved the problem with a simple property check before attempting to set anything:

	if (F_ApiGetInt(docId, elemId, FP_AttrDisplay) != FV_ATTR_DISP_REQSPEC)
	F_ApiSetInt(docId, elemId, FP_AttrDisplay, FV_ATTR_DISP_REQSPEC);

Previously, there was no cost if you attempted to set the property to its current value. Apparently that has changed.

Russ

[frameexpert]

Hi Russ,

I am not sure if this is related, but somewhere along the line, some of the properties appear to be "stack-based" instead of boolean. For example, I used to just use this:

app.Displaying = 0;
...
app.Displaying = 1;

But after a certain version (I can't remember which), FrameMaker would hang for a few seconds if you tried to set the property to its current setting.

The solution is what you have discovered:

if (app.Displaying === 1) {
    app.Displaying = 0;
}

and

if (app.Displaying === 0) {
    app.Displaying = 1;
}

Someone at Adobe told me about the "stack-based" thing but I can't find the email or remember who it was. But your situation is probably related.

-Rick

[Russ Ward]

Yeah, Rick, thanks. I did run into that Displaying thing a while back. If I recall, I saw even more serious behavior, like the window just locked up if I set Displaying on when it was already on.

Russ