[eronel]

I have a large number of completed actions (woo-hoo!) and in context mode I do get a delay when viewing completed. Not as long as in planning mode though.

[Tim Wood]

Thanks for the info; I'm still having no luck reproducing the problem with small projects (I can of course slow it down by using a project with a hojillion incomplete actions).

If someone could send in their prefs and app support directory, I'd love to get to the bottom of this before we freeze 1.0. Just let me know the RT number and I'll take a look.

[Toadling]

My theory is that this has more to do with the number of items in the sidebar rather than the size of individual projects. I am able to reproduce the issue with a test database containing the default projects duplicated over several times with a few nested folders thrown in for good measure.

I sent the test database along with my preferences file to the feedback address with the string "For Tim Wood" append to the subject line. Reference OG #240793 and OG #240795.

When I select one of the top level projects in the test database and hold the down arrow key, scrolling from one project to the next feels sluggish, as does clicking on any item in the sidebar with the mouse.

If I then delete about half the items or more, the same scrolling procedure is significantly faster, and so is selecting items with the mouse.

Maybe this is just a consequence of having too many active projects, and I might be willing to just live with it, except that it seems like this sluggishness did not exist prior to rev 95633. Unless I happened to coincidentally hit some kind of threshold in the number of projects around the same time the rev 95633 build came out?

[Tim Wood]

Yep; it looks like (at least part of) this is related to the number of objects in the sidebar. I'm looking into it now.

[Helo]

Originally Posted by Tim Wood

Yep; it looks like (at least part of) this is related to the number of objects in the sidebar. I'm looking into it now.

Thanks.

I have noticed a slow down too (starting yesterday), and it is just to the point of making OF maddeningly annoying to use. I suspect that this may have to do with some "threshold" with the number of projects and folders. I started noticing this around the time when I had added a bunch of new projects.

[Tim Wood]

In 95715 I've added a hidden default that will help verify that I've diagnosed the problem (I know it makes it better for me). Could you all try:

defaults write com.omnigroup.OmniFocus LeaveEmptySelectionEmpty -bool YES

in Terminal.

This will make OmniFocus show _nothing_ in the content area if you have nothing selected in the sidebar (instead of showing everything). It seems like the issue is a possible bug with Mac OS X where changing the selection in the sidebar causes us to temporarily act as if we've deselected everything (which makes us effectively select everything w/o this default) and then re-narrow the selection.

With this set, I can down arrow through a list of 1300 top level projects nearly very quickly.

Hopefully I'll get a workaround back from Apple soon and will be able to make this work for real.

[Helo]

Running the command in Terminal did not do anything for me. Maybe I was not running it correctly.

Nonetheless, upgrading to the latest build (95718) did resolve the issue. Now I can arrow down pretty quickly with all items open in the sidebar AND all actions showing. Mouse clicking works well too.

Thanks for the rapid fix.

[Toadling]

Tim:

Much better! Setting the new defaults key greatly improves performance for me.

I gather the "show _nothing_ in the content area if you have nothing selected in the sidebar" behavior is intended as a temporary work-around? But I wonder if this should instead be the default behavior. After all, if I want to see everything, I can just click the Library folder. At least some other apps function this way (e.g. Yojimbo).

Selecting nothing also allows me to leave Project mode in a clean state that's very fast to return to from Context mode. Now I can toggle back and forth between the modes lightening-quick!

Helo:

Did you restart OF after running the defaults command in Terminal? I suspect the performance improvement you're seeing is not from rev 95718 (at least I didn't see any speed difference from that build without the hidden default) but rather because your defaults setting only took effect after you launched the new app version.

[eronel]

It's better today-- no more 3 second delays loading the library, now it's about 1.5 seconds to go from the bottom folder to Library with all actions showing. With only next actions showing, it's probably around 1/3 sec. But the defaults change did not make a noticeable difference. I'm running v95718 now, was on 95656 and 95634 yesterday.

[Toadling]

eronel:

I'm surprised to read that the defaults change didn't make any difference for you as it made a HUGE difference for me. Perhaps you didn't relaunch OF after the change? Here's the procedure I followed:

(1) This morning, I first updated to rev 95718 and saw little or no performance difference.

(2) Then I quit OF and applied the defaults change and restarted OF. The sluggishness in selecting sidebar items was gone.