• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

FM 2019 - Open/save files is very slow

Mentor ,
Dec 12, 2018 Dec 12, 2018

Copy link to clipboard

Copied

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

TOPICS
Scripting

Views

783

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Adobe Employee , Dec 12, 2018 Dec 12, 2018

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

Votes

Translate

Translate
Adobe Employee ,
Dec 12, 2018 Dec 12, 2018

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Mentor ,
Dec 12, 2018 Dec 12, 2018

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Mentor ,
Dec 14, 2018 Dec 14, 2018

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Mentor ,
Dec 14, 2018 Dec 14, 2018

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 14, 2018 Dec 14, 2018

Copy link to clipboard

Copied

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Mentor ,
Dec 14, 2018 Dec 14, 2018

Copy link to clipboard

Copied

LATEST

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines