OO5 very slow compared to OO3?

Is anyone else experiencing very slow performance with OO5 when editing very large outlines (> 1MB), especially relative to the performance of OO3? I currently use OO3, and would like to upgrade, but the performance of OO5 is so much slower compared to OO3 (in my limited experience with the trial version). Specifically, I have a very large outline that is about 4MB. The outline file is the simplest possible, with NO added styles anywhere. When I open it in OO3, it take about 10 sec to open (machine and system listed below), but when I open it (the same exact file, after all the conversions to OO5 format, and again, making sure all styles are removed by applying the most basic template that has no styles, etc.) in OO5, it takes about 2-3 minutes. If I had to suffer a long start-up and that were it, I could probably tolerate this (because it is a file I keep open all the time), but what’s worse is that when I try to edit the outline, it’s common that the Mac balloon appears causing a delay before I can enter anything. The responsiveness of OO5 makes the program unusable.

I would really love to upgrade, as I am a long-time user of OO, but unless I’m doing something wrong, the performance of the upgraded version is so much worse than OO3 that the upgrade is not viable for me.

Is this a common or known problem? Any suggestions?

System: MacBook Air 11 (mid-2011), 1.6 Ghz Intel Core i5, 4GB RAM, 128GB SSD
OS: Mac OS X El Capitan, 10.11.6

2 Likes

We have a number of performance fixes coming in what’s currently planned as the 5.2 release that are under going testing. There should be public test builds available in the coming weeks that you can try out.

Hmm. I have a frequently-used outline that’s 22.5MB and I see no significant slowing down in OO5. Even at that size, it takes only about 5 seconds to open.

This might be attributable to the difference in our systems: I’m running a 2015 iMac with a 4GHz i7, 16GB of RAM, and the latest OS, 10.12.5. Have you tried upgrading your OS?

What I’m running is not far off rogbar’s machine (Mid 2015 MBPro 2.5 GHz i7, 16GB ram, OS 10.12.5) and I think the slow-down is real. I’ve used my file continuously since the early days of oo3. It’s now 182 MB, and the xml content alone is >11 MB. (I’ve converted it from oo3 to OOOutline file format.) For quite simple actions, like switching focus sections using the sidebar, I get a couple of seconds of spinning pizza, which is tough, given frequent and daily use.

@joepas58, First, I’d be cautious about upgrading to the latest OS, because my experience is that after upgrading to Sierra, I was unable to run OO3. Second, if you haven’t already, try format-converting a test duplicate of your large file — it could improve things a bit.

I am having a similar problem. I have the same machine as JohnWhite, and am working with a 220 MB file that has been growing for several years.

My problem is not a long time to open the file. Rather, when I switch to a new item (using the cursor), I often get 5 to 12 seconds of “spinning beach ball.” Checking Activity Monitor shows no unusual CPU or other load, so I have no idea what is happening.
Similar to this description “what’s worse is that when I try to edit the outline, it’s common that the Mac balloon appears causing a delay before I can enter anything. The responsiveness of OO5 makes the program unusable.”
The problem occurs even for trivial moves, e.g. from

The program is not quite unusable for me, but it is slow and frustrating. Unfortunately, I don’t know if it’s possible to return to the previous version, but if this continues I will have to figure out how to downgrade.

1 Like

By the way, the problem is much reduced by opening large sections of the outline at a time. There is a delay the first time a section (even a small one) is expanded. But after that, scrolling around within the expanded section takes no additional time. Thus it appears that opening a section of an outline (by clicking on the triangle) requires a long delay to load that section into active memory, but thereafter it is always available.

I will experiment with expanding the entire outline when I first open it, then selectively closing it again. This might help.

For me, the delay (about 10-15 sec) occurs every time I switch to OO5, regardless of whether the section was already expanded or not. It is very disconcerting to be working, switching quickly between various applications, and then switching to OO5 and hitting what seems like sludge - it really affects the workflow. I have been working with OO3 and OO5 side-by-side, using mirrored versions of the same file (yes, I’ve been updating each separately during this test phase of OO5), and while OO3 is a delight to use, OO5 is the opposite. By the way, the OO5 version of the file is generally about twice as large as the OO3 version. These are text files (no images, etc.), the former being about 4MB and the latter about 2MB, despite they have the same user-generated content. They are also very old, having been created in OO2, continuously updated to the present day.

1 Like

Thanks for reporting the problem! It would be very useful to get a sample of what the app is doing during those 10-15 seconds of delay:

https://support.omnigroup.com/sample-osx/

If you can collect that sample and email it to our support humans (at omnioutliner@omnigroup.com), that will help us understand whether the issue is caused by autosaving your document, or rendering the outline to the screen (OmniOutliner 5 does a lot more work in its display logic than OmniOutliner 3 did, because of its support for Retina displays and its animation of changes to the outline), or perhaps some other mystery. (In previous investigations, for example, we’ve found that looking up the current size for a printer page can cause hangs when the default printer is unreachable.)

Thanks for your help!

Unfortunately, I had to switch to Sierra and lost the ability to use OO3. In my experience, OO5 is much slower for large outlines (I have >5200 rows): slower to open, very slow to open the Inspector, and slow to search (using the batch find field). Scrolling through the file is also much choppier.
I am not using any fancy features likes styles or notes, but I do have a lot of linked files in the outline.

1 Like

Just wondering whether there is an estimate on when 5.2 will be released?

OO is an overpriced program not optimized to take proper advantage of a computer. This makes it unusable for anything but fairly small files: NOT a pro app despite its deceptive positionning.

I’m pissed because like many other users having paid ~$70-100 for single Omni Outliner apps I have been losing countless hours due to its poor performance and am now stuck with long documents who can’t be used and edited efficiently despite working on $4-5,000 machines from Apple.

As you say when it “freezes” it never uses more than one thread of the CPU, using max 25% and as low as 2.8% of the processing capacity at hand on the current Mac lineup meaning it could accomplish tasks ~4-30x faster than it does on tasks whose performance is limited by processing tasks (such as seems to be the case when collapsing rows). Talk about a Pro App…

2 Likes

As a long time OmniOutliner user, I am also VERY discouraged with how incredibly slow OO5 is compared to OO3. I used to praise OO3 every day; now I curse OO5 every day. I have sent a number of specific issues to OmniOutliner Support. Just found this forum entry and thought I’d repost them here as well. Maybe others can chime in if they have the same issues.

An OO5 issue: Sent to OmniOutliner Support 2017-10-06 Search term entry cuts off too early: When entering a word or phrase in the Search box, it tends to stop after just 3 characters and start processing the search. Spinning beach ball almost every time. When it finally does finish, I then type the rest of the word, get more wait time, and finally the search results show up. Please consider adjusting the time allowed to enter a search phrase or make this a user configurable parameter.

Another OO5 issue: Sent to OmniOutliner Support 2017-10-06 Paste function: Macs (and almost all Mac versions of most applications) have long had a clear distinction between the Paste command (Cmd-V) and the Paste and Match Formatting command (Opt-Cmd-Shift-V). Many users like myself have the distinctions long engrained and use the shortcut keys automatically. You have switched those, such that Cmd-V is now the Paste and Match Formatting command (although you still call it Paste in the menu) and the Opt-Cmd-Shift V is now the regular Paste command (which you call Paste With Original Style). YOU SHOULD NOT HAVE DONE THAT! Please change this back so OO matches normal Mac conventions with regard to Paste functions (or make this a user configurable parameter).

1 Like

Another OO5 issue. Sent to OmniOutliner Support 2017-10-06 Filter mode vs. Batch Find mode in the search box. While it seems like Filter might be useful to some folks, it almost never is for me. I want to see the context that comes with Batch Find, and especially to scroll up and down in the sidebar with the Batch Find items showing, and click on them to see them in context within the file. Wouldn’t mind that Filter was an option, but there’s no way to configure OO5 to make Batch Find the default, which I really want to do. Please consider making Batch Find the default, or at least making it a user configurable preference.

And another OO5 issue: Sent to OmniOutliner Support 2017-10-06 The whole Focus/Unfocus is a pain. It used to be the case (earlier versions of OO) that you had sections, and you might be in a particular section, but when you did a search you were always searching the entire document. You didn’t have to mess with selecting multiple sections, trying to guess which section the item you were searching for was in, or Unfocusing the work area before doing your search. This just adds more steps and obstacles to using the application efficiently. It is a step back in functionality that negatively impacts long term customers. Please allow users to work in a particular section but have searches that are entered in the search box search across the entire document (or make this a user configurable preference).

Another OO5 issue: Sent to OmniOutliner Support 2017-10-06 The sidebar used to slide out from the main outline window without changing the dimensions of the main outline window. The sidebar would slide out and make the total OO window wider, but the main outline window size would not change. As a result, the view of the content in the main outline window didn’t change as the sidebar was slid out and then slid back. Now (v5.1.4 Pro) when you slide the sidebar out, different files behave slightly differently, but none behave as they used to (which, to me, was preferable). In some files the sidebar slides out within the confines of the main outline window, and squeezes the main outline window, making it narrower and also changing the view of the content in the main outline window such that whatever row you were working on has now moved up or down and out of site. In other files the sidebar also slides out within the confines of the main outline windows, but rather than squeezing the main outline window it pushes it to the right, truncating the view of the content (which can now be scrolled left and right). This has resulted in my having to leave the sidebar open all the time. This in turn causes the entire OO window to be wider than I would like, taking up more real estate. I much preferred being able to make the OO main outline window fairly narrow, so I could push it to the side of my screen and take notes while still seeing other apps and windows on the rest of my desktop. When I needed to search for something, I’d open the sidebar, do the search, then when done close the sidebar. BTW, that was all on a laptop. I never minded having the sidebar slide out, making the total OO window wider during the time I was using the sidebar, since that was generally short lived and I’d then slide the sidebar closed again. Please consider changing back to having the sidebar slide out to the left of the main outline window.

Agreed. It’s dog slow. I made a video of my cursor, clicking between two windows. It’s about 14 seconds for one back-and-forth. I have two outlines, 70MB each.

I am looking forward to finishing the project I’m use OO for, then dumping it forever. I tried the iPad version, and wow, I don’t see how anyone can do REAL work. Copy…wait…click…wait…paste…wait…

And some people think looking at two docs at the same is a fluffy-feature for iOS? Really?

Too bad.

This sounds like the document autosaving as you switch between windows (which is a standard macOS behavior since Lion), and taking a long time because of the size of the document.

Have you tried tuning the document settings? In the Document Inspector, under Format and Metadata, there is the option to Save as flat file or Save as file package. For large documents, Save as file package is likely to be the better choice—especially if you’re saving to a old-style hard drive with a spinning platter rather than one of the newer (and much faster) solid state drives.

Thanks Ken! I am trying that document setting and it seems to help! I wish there were a way to disable the auto-save when switching.

I agree with most of bseixas’ issues. The “focus” is somehow not quite right yet. I find I need to click it off more than I think, “Yes, thank goodness it’s been focused”. It reminds on the Microsoft Outlook mail-filtering, which really screws up a lot of things.

I am also trying this, from an old StackExchange. My System Preferences was already checked (off). This is seems to address a completely different problem. Ymmv. If you mess up your system… https://apple.stackexchange.com/questions/27544/how-to-completely-disable-auto-save-and-versions-in-mac-os-x-lion