CIB merge can output the result file not only in RTF format as a file on the hard disk. It can also use different parameters for optimization, compression and/or encryption of the result data stream.

1. No matter which root is merged with, the include cache is effective regardless of the jobs that are sent within a merge call.
2. The root is currently not included in the include cache yet. They include cache is only for includes.

 

Note for 2.: However, there has always been another optimization for the root: If you specify the -I parameter and mix it once, the root remains in memory until you specify -I again.

So if you mix many files with the same root directly after each other and specify -I only once, you will have the same cache effect.

 

Note for 1. and 2.: The optimization via the include cache is a trade-off for runtime at the expense of memory and functionality:

If you mix with root X, then for X the font tables, color tables etc. are changed (extended) with respect to the respective include. On the other hand, the font, color, etc. keys (\f12, \cf1...) for the includes are adjusted with respect to the current root and thus stored in the cache.

If the roots "fit together", then the colors, fonts etc. will be correct afterwards. If not, then not.

So to have absolute security, you have to mix documents with the same root one after the other to have the cache advantage and then empty the cache. After that you can mix with the next root, etc.

The cache can be cleared indirectly with one of the commands for controlling the behavior of the include with regard to fonts, colors, list tables, etc. For example, a single --replace-header is sufficient to clear the cache. (The default --replace-header=always is set, but it should be valid anyway).

 

Because of the last hint or rather because of the way the tables are merged from the header of the RTF, a root cache is mostly not useful and because of the necessary sorting of the requests by root not necessary.