[Jay Levitt]

Some time in the last few days, opening the Quick Entry panel started taking a full second to open up on my Mac Pro (8-way Xeon 3.2GHz, 16GB RAM) - whether I use the keyboard shortcut, or the "Toggle Quick Entry" menu item on OF's Window menu.

Before I start narrowing down what Sneaky Peek version introduced the problem, is anyone else seeing it? is Omni already aware of it?

[ext555]

a full second ? how long did it take before . Seems like it might be hesitating another millisecond but it doesn't really bother me .

[Toadling]

I haven't noticed any difference on my system, but I haven't really paid close attention. I'll take a closer look when I'm back at my desk (on the iPhone right now).

-Dennis

[beharkey]

I'm using a 4-core 3.0Ghz Mac Pro and Quick Entry is practically instantaneous for me.

[Jay Levitt]

It used to be instant (like just about everything else on an 8-core desktop :) ).

A few days ago, I dragged the contents of my 400-item inbox into a new Library folder called "Backlog". That seems to be what's making the Quick Entry field slow; if I restore to the backup just before I did that, Quick Entry pops up instantly.

dtruss shows that when OmniFocus is using the post-"Backlog" database, it calls gettimeofday 259 times when it opens the Quick Entry window. With the pre-"Backlog" database, it doesn't call it at all. So that could be the culprit.

I can't figure out what about the Backlog items is so different, though - at least not 259x different. (There are 413 items in the backlog folder.)

Omni, here is a sample entry from the Backlog filder:

<task id="g4oT8unoDTw">
  <project>
    <folder idref="oYJzm9E-4FL"/>
    <last-review>2008-09-25T04:00:00.000Z</last-review>
    <review-interval>@1w</review-interval>
  </project>
  <added>2008-08-13T23:46:57.267Z</added>
  <modified>2008-09-26T00:32:26.352Z</modified>
  <name>iTunes convert FLAC to ALAC</name>
  <rank>1559915286</rank>
  <order>parallel</order>
</task>

And here's a sample project and action from the "regular" part of the Library:

<task id="os0Lp5Y_cSj">
  <task idref="jGEWWZR1UsV"/>
  <added>2008-09-23T13:54:10.340Z</added>
  <modified>2008-09-23T13:54:17.996Z</modified>
  <name>Find old Apache config files</name>
  <rank>0</rank>
  <context idref="asqnczMIH4C"/>
  <order>parallel</order>
</task>


<task id="jGEWWZR1UsV">
  <project>
    <folder idref="cmE7aLZnRzs"/>
    <last-review>2008-09-23T04:00:00.000Z</last-review>
    <review-interval>@1w</review-interval>
  </project>
  <added>2008-09-23T13:53:38.861Z</added>
  <modified>2008-09-23T13:54:17.996Z</modified>
  <name>Recreate wiki</name>
  <rank>-1879048192</rank>
  <order>parallel</order>
</task>

The only obvious difference is that the Backlog item is a project with no action. But, again, that'd be true 413 times, not just 259.

So... if anyone at Omni wants me to e-mail them the bad file, lemme know..

[Toadling]

Maybe you should contact the support ninjas via Send Feedback under OmniFocus' Help menu. They may or may not respond to your post here.

As for speed based on number of CPU cores, I don't think it really makes any difference in this case unless you're seeing a huge spike in CPU usage when you open the quick entry window.

-Dennis

[Jay Levitt]

Originally Posted by Toadling

Maybe you should contact the support ninjas via Send Feedback under OmniFocus' Help menu. They may or may not respond to your post here.

Truth, I posted it here because out of 9 messages sent to the ninjas, I've had zero useful replies. I know they're behind, but even when they do catch up, the answer's always "I'll add that to the development database". As far as I can tell, none of the bugs I've reported there have ever been fixed. Posts here tend to catch Omni's attention better.

(I realize that the iPhone launch, and the simultaneous launch of the best-but-necessarily-most-complex multi-way sync I have ever seen, has sucked up a lot of the dev resources lately. I hope that, with most of the sync bugs fixed, and the upcoming Bonjour support, they can get back to fit-and-finish issues soon.)

That said, I can't very well complain if I don't keep trying, so I sent this one in too (OG #366290).

As for speed based on number of CPU cores, I don't think it really makes any difference in this case unless you're seeing a huge spike in CPU usage when you open the quick entry window.

Well, actually, I was seeing a spike. But the point (which I didn't make very well) was that a one-second delay on a MacBook Pro can be a normal thing; a one-second delay on a fast desktop is rare. I have a four-drive, 15K SAS RAID-10 array, 16GB RAM, and 8 cores. Even PhotoShop launches in under 10 seconds; most other actions occur by the time I let go of the mouse button. So, while "a whole SECOND!" doesn't sound very slow - it really is, and I'm sure it's even worse on the average laptop.

[Lucas]

Originally Posted by Jay Levitt

A few days ago, I dragged the contents of my 400-item inbox into a new Library folder called "Backlog". That seems to be what's making the Quick Entry field slow;

Why not add projects and contexts to those inbox entries and have them sorted? Don't you have to do that anyway?

[whpalmer4]

Lucas, I'm guessing the choice of name for the folder ("Backlog") is significant :-)

[Jay Levitt]

Originally Posted by whpalmer4

Lucas, I'm guessing the choice of name for the folder ("Backlog") is significant :-)

Actually, the real time-saver would be to just do all 400. Then I wouldn't even have to write them down!