Using FM 2020 (16.0.1).
We have recently begun using FM 2020, structured, with DITA 1.3. We are finding that the search function is incredibly slow. It is so slow as to make it almost unusable. When I search for a phrase that is in the last file in the DITAMAP, it takes 240-280 seconds (i.e. 4-5 minutes). When I search for that same phrase using Notepad++, it takes 6-7 seconds. This difference in speed is a factor of 40-50x.
We have a few hundred DITA files in the DITAMAP (i.e. moderate size) and all files are stored locally on my hard-drive (i.e. the slowness is not due to network considerations).
Does anyone else experience such incredible slowness with the search function? Why is it 40-50x slower than Notepad++?
As FrameMaker opens topics, it may be trying to resolve conrefs, cross-references, etc. If you go to Structure > DITA > DITA Options, you can turn some of these things off. Also, if your Cross-References pod is visible, this can significantly slow FrameMaker down.
Thank you for the quick response.
I do not have the Cross-references pod visible.
I unchecked all 3 of the auto-load On File Open options and re-tested. It still took ~ 150 sec to find that search time, which is ~20x slower than searching with Notepad++.
I am curious - do you find similar discrepancies between Notepad++ (or any other similar tool) and Framemaker 2020? These search times with FM are so incredibly slow on my system, I am surprised that I could not find anyone else complaining - which makes me wonder if there is something wrong with my installation rather than something wrong with Framemaker (hence I am curious if others also experience very slow search times).
This is an area that we do plan to investigate in the upcoming months. Hopefully you could look at a fix for this in an update for the latest release.
Hope this helps.
FrameMaker is painfully slow on a lot of tasks, but maybe we old-time FrameMaker users are just used to it. Since Adobe bolted on their OWL interface back in FrameMaker 9, performance has suffered overall. FrameMaker 8 was quite fast as I recall. But I like what FieryPantone says: it's useful to have other tools to switch to for certain tasks. I use Oxygen XML Editor to do some of my heavy XML processing because it has so many good XML-oriented tools. It is not free, but I need a good tool for XSLT development, etc. For some projects, FrameMaker has just become an expensive "print engine" to get nice PDF output.
More of an observation than an answer, but we don't always have to do everything within a single tool; so turning to a text editor for searching .xml files is not a sign of weakness :-} I quite often use Notepad++ or even gVim to search through a stack of DITA files, then step back into my DITA environment to carry in editing what I've located.
I very much like and agree with this, @FieryPantone. I use Notepad++ quite often as well (and more and more often UltraEdit) for all kinds of simple source code editing or such cross-file find/replace operations that do not require a "WYSIWYG" view and structured content awareness and DITA-Features resolving (like conref processing).
I see such tools as little helpers that are great for a particular task and are very useful in a complementary way.
This comment is a bit a general query, but it sounds like others have also experienced FM to be painfully slow, and that this sluggishness has been a long-standing problem. Have others complained to Adobe about these problems before? I just searched the Adobe bug/feature tracker, and could not find anything related to speed/sluggishness (other than an issue that I just created there - FRMAKER-9669).
The Adobe employee who responded to this post said that they are looking into this issue, but I am wondering why this problem has not been resolved previously.
Since I originally started this topic, I have been using FM and have observed that the slowness I mentioned previously affects related behaviours as well: find/replace, spelling, tracked changes, etc. While it is not surprising that all of these related functions show the same problem of slowness, I mention this observation because it demonstrates the widespread effect of this issue on overall usability.
To allow an apples-to-apples comparison with other users, I have created a sample DITAMAP with files for testing purposes. These sample files have been attached to https://tracker.adobe.com/#/view/FRMAKER-9669. I then ran two different tests (each was run multiple times) to compare the speed of searching for text within Framemaker vs. Notepad++.
Unzip the ZIP file from https://tracker.adobe.com/#/view/FRMAKER-9669 to its own directory.
1) Start FM (I use 16.0.1)
2) Open the ditamap
3) From the ditamap, right-click on the first DITA file (lorem_ipsum_text.dita) and open it.
4) Click on some of the text in the newly opened DITA file
5) Open the Find dialog, and select “Text” from the drop-down menu.
6) Type “FINDME”
7) Click Find and time how long it takes for FM to find this text (which is in the last file…)
1) Start Notepad++
2) Select Search -> Find in Files
3) Under Find what, enter "FINDME"
4) Under filters, enter "*.dita; *.xml; *.ditamap"
5) Select the directory containing the DITA files from this example
6) Click Find all and time how long it takes to return a result
Test #1 (FrameMaker): ~34 s
Test #2 (Notepad++): < 2 s
Please test and post your results here.
OK. On my system (with some other applications open) FM took 18 seconds. Laptop with i7, 16 GB RAM.
I do not use DITA. However, I think that FM has to open and process the single DITA files when you search for text.
This would explain why Notepad++ is faster.
I agree that the performance of FrameMaker has to improve when it comes to such DITA-XML related operations like file opening, find/replace, etc.
However, it does not make much sense to compare performance in find/replace operations between FrameMaker and Notepad++. Notepad++ is a plain text editor, not an XML editor. It does not need to "understand" XML and it's structure. Notepad++ does not make any difference in a find/replace operation between XML elements (tags) and attributes and the content itself (PCDATA). It also does not validate the XML for compliance with the DTD, does not resolve cross-reference, variables, linked images, conrefs, keyrefs or any other "content feature" that DITA and FrameMaker offer. Also, it does not "translate" (render) the XML into a full-fledged page layout and does not apply any (contextual) formatting rules like "if this element is a child of x format it this way, and if it is a child of y format it this way."
In a nutshell: For Notepad++, DITA XML files are just simple plain text files with "meaningless" strings of characters. If you search for "note" it will return both the strings "note" in the XML element "<note> as well as "note" in the PCDATA "Please note that …". Even if it is only for that, such "blind" cross-file find/replace operations need to be done very consciously and carefully with Notepad++ (or any other plain text editor). It also does not validate the structure after making changes and if a find/replace operation made the XML file invalid.
That said, if you do a cross-file find/replace operation with Notepad++ (or any other plain text editor) it can be of course lightning fast. Simply due to the fact, that Notepad++ can just "stupidly" finds and replaces simple character strings with brute force, while FrameMaker actually processes XML with all the complexity and computational effort and cost that comes with it.
This is not an "excuse" (again, I completely agree, that performance needs to improve and performance improvements are an ongoing effort that we constantly work on), but an "explanation" why there is such a big performance difference between a plain text editor and a full-fledged XML editor + DITA-Engine + XML Layout and rendering engine.
Again, we are constantly looking into performance improvements for FrameMaker (it's actually one of my favorite topics in discussions with the engineering team), but FrameMaker will probably never be as fast as "simple" text editor like Notepad++. There is simply a much bigger computational cost associated with all the DITA XML validation, resolving, and layout rendering in what a complex XML Editor like FrameMaker does. You cannot develop that away. It can be improved, but not ignored.
I have not tried the newest Framemaker yet (2022 release from Sept), but according to the New Features, they have addressed this problem:
"DITA search performance improvement ... the search performance has improved by 15 times "