Why does a simple save take so long?

[FMdancer]

I am using FM 11. I have 18 files with lots of figures and perhaps this is part of my issue. It seems to take between 1 and 2 minutes every time I save. Is there some setting or some trick I can use to shorten the time FM takes to save my book or chapter? Thanks.

[Arnis Gubins]

Are you saving to local drives or across a network? Are the graphics imported by copy or reference?

[FMdancer]

I am saving to a local drive and have many of the figures references in instead of embedded.

File sizes are:

218.8MB

20MB

3.7 MB

and 15 other files all under 200 KB

[Bob_Niland]

> I am saving ...

Saving what? .fm .pdf ?

> 218.8MB

> 20MB

If those are PDFs, yes, that takes some time (if you already have 16GB RAM, get an SSD).

If those are .fm files, you have a degenerate situation of some kind, probably huge embedded objects. Is the size growing with each open/save/close (and no other edits)?

[FMdancer]

All .FM files.

[Bob_Niland]

> All .FM files.

>> Is the size growing with each open/save/close (and no other edits)?

[FMdancer]

the 20MB file was 44MB before a MIF wash a week ago. The larger file has been about that size for at least a month. I probably have more embedded pictures than I thought.

[Arnis Gubins]

The 20Mb & 218MB files indicate that the graphics are imported by COPY or that you have the "Save FrameImage with imported graphics" option in your Preferences turned on. In either case, FM has to do a lot more work to save large internal graphics.

[FMdancer]

Arnis - I have started to replace the embedded pictures and have seen a small change in the file size. Thanks for your insight.

[FMdancer]

Files are not growing with each save and my preferences show the Save FrameImage with Imported Grpahics unchecked. I believe I need to replace the embedded pictures with referenced pictures. Thanks for all the feedback.

[Bob_Niland]

> Files are not growing with each save ...

That rules out recursive Text Inset imports (that import themselves). Your problem is apt to "merely" be instances of copy-into-document.

If you need to hunt, save the document as MIF and open it with a plain text editor.

All imports contain the tag:

<ImportObject

By-Reference Imports look like (EPS example):

<ImportObject

   ...

   <ImportObFileDI `<u\><u\><c\>path<c\>filename.eps'>

   <ImportObFile `../../path/filename.eps'>

Copy-Into Imports lack those <ImportOB... tags, and look like (EPS and TIF examples):

  <ImportObject

   <Unique 3288853>

   <Fill 7>

   <Separation 0>

   <ObColor `Black'>

   <RunaroundGap  6.0 pt>

   <RunaroundType Contour>

=TIFF

  <ImportObject

   <Unique 3288835>

   <Fill 7>

   <RunaroundGap  6.0 pt>

   <RunaroundType Contour>

=EPSI

followed by metadata and thousands of lines of hex code.

Clue: the original file name of the imported object can often be found in the meta, but the presentation varies with file type.

Alas, as you can see with
select object in frame
Graphics > Object Properties,

Frame pretty much forgets what an import was, and where it came from, when (*) Copy Into is used. Big problem for information stewardship, not to mention capacity planning.

[Winfried Reng · Accepted solution]

In FrameMaker 11 you can also use the the Inset pod to check which imported image is copied into the document.

Open the Inset pod with View | Pods | Insets.

Referenced images show the path.

Images which are copied into your document show "No File".

Much easier than reading the MIF file tags.

[Bob_Niland]

> Much easier than reading the MIF file tags.

Indeed, unless the rogues are not visible in their frames: negative or out of range origin, hidden behind something else, not to mention conditional frame anchor presently hidden, anchored to text flowed out of sight in disconnected frame, or entire frame obscured by degenerate page layout, etc.

Unless newer FM versions have added Any Imported Object to the list of targets for Find, and you can manage the event of a hidden find target, a raw MIF search may be the only solution.

[FMdancer]

Thanks for the tip about the inset pod. This will be very useful and quick for replacing those embedded figures.

[Bob_Niland]

Save as what to where?

If normal File > Save for the .book and .fm, how large are the .fm files?

As Arnis suggested, embedded objects can over-inflate file sizes (as well as present various stewardship and data-preservation problems).

Save as PDF is just plain slow, pretty much always, and even slower when referenced objects and output files are located on network drives.

[FieryPantone]

Save as PDF is […] even slower when […] output files are located on network drives.

So, how can I make sure that output files are written direct to a local drive? Eager technicians are poised to take my PC and <strikethrough>wreak havoc</strikethrough> deftly install FM 12, so if there's something I can tell them before they start this could be a good moment.

[Bob_Niland]

> So, how can I make sure that output files are written direct to a local drive?

With current active directories, virtualization, mounted volumes, etc., only Mordac, Preventer of Information Services, really knows.

FM uses the document directory for the backup and crash files during edit, and for the visible .tps file during render. It is obviously using virtual memory (which may get swapped to disc) during edit and render, and may use some transient files in $TEMP or $TMP.

When I build a machine, I normally allocate dedicated logical drives for temp and VM, historically on separate spindles, to maximize performance, eliminate fragmentation risk, and guarantee adequate space; but that might freak out your Mordac team. My current build has these on an SSD. The traditional HDDs (aka rotating rust) on the machine are only used for backup and archives.

If a document resides on the network, moving it to a known local drive can speed things up, but raises the problem of imported objects. You'd need to re-save all the files to local, render, and if any changes were made, re-save them back.

[FieryPantone]

… and I am both delighted and enlightened by discovering Mordac – such keen observation :-}

[FMdancer]

Niels - I have copied my files to my local C drive and backup nightly into a version control system. When I have a major delivery I copy the source FM files on the network drive with a PDF version of the book. It is much faster than working daily with networked files.

[FieryPantone]

[replying to Error7103 and to FMdancer] Working with source files on a hard drive and being diligent about back-ups to network sounds like a good idea. I'll give it a try!