[whpalmer4]

Ken, would it be useful to describe how to use the iPhone Configuration Utility to grab the console log from the offending devices after turning on File Manager Debug? Seems like the timestamps would give some concrete evidence as to whether the same bug is biting everyone.

[Brian]

Originally Posted by beharkey

ADDITIONALLY, has anyone noticed that sometimes when you open the iPhone version of OF, it takes a LONG time to go through the process of "Optimizing Database"? Sometimes on the order of a minute or two for me.

This is the problem that Ken mentioned in this post; the app is currently doing the last step of the sync process (after the files have all been fetched from the network) pretty inefficiently.

[JohnJ80]

Originally Posted by Brian

This is the problem that Ken mentioned in this post; the app is currently doing the last step of the sync process (after the files have all been fetched from the network) pretty inefficiently.

what is the ETA for the next release?

J.

[manispace]

Originally Posted by manispace

I'm having the same problem. Syncing OF iPhone usually takes 1 minute or longer (up to 4 minutes).

And here's the thing: When I sync OF Desktop over the same connection (Internet Tethering) it takes no longer than 5 seconds.

Could Calendar Export be causing the long sync durations? I have quite a few due dates assigned. That could explain why OF Desktop syncs faster and why only some users experience long OF iPhone sync durations.

Hope this problem gets solved soon.

[Brian]

Originally Posted by manispace

Could Calendar Export be causing the long sync durations? I have quite a few due dates assigned. That could explain why OF Desktop syncs faster and why only some users experience long OF iPhone sync durations.

Keep in mind that Ken may hop on here and correct everything I'm about to say. :-)

My understanding is that the bug in question is in some iPhone-specific code, but it's not related to the Calendar sync feature. Instead, it's related to the number of change files that the phone is processing. Folks with a smaller number won't see as much delay.

[Greg Jones]

Originally Posted by Brian

My understanding is that the bug in question is in some iPhone-specific code, but it's not related to the Calendar sync feature. Instead, it's related to the number of change files that the phone is processing. Folks with a smaller number won't see as much delay.

I'd agree that the calendar export is not the cause here. I turned export off two days ago in the hope that sync time would improve, but I've not seen any reduction in my sync times.

Having said that, I'm also wondering if it involves some bug other than just the number of change files. I've trimmed my database down, synced yesterday, and turned the phone off and on to clear memory. I synced over my network again first thing today without making any changes in either database (other than the automatic changes that occur at midnight) and my sync time was still almost 70 seconds. The stats for the database are 40 projects, 257 actions, and 2 zip files-not exactly a behemoth database compared to some of the other stats I've seen mentioned on the forum.

[Ken Case]

Originally Posted by Brian

Keep in mind that Ken may hop on here and correct everything I'm about to say. :-)

Well, just one minor correction…

The issue I was talking about has to do with how many new changes were just synced, and affects both the Mac and iPhone versions (but the Mac is so much faster that it's less commonly noticed there).

The test case I have is from a review I did last weekend on my iPhone and laptop, and I identified the problem because when I synced those 192 changes back to my Mac Pro it took 20+ seconds to sync: long enough that I was able to use Activity Monitor to grab a sample of the process and track down the problematic portion of the code.

I took a snapshot of the sync database to use as a test case, and found that (ignoring sync transfer times from the WebDAV server) it took my iPod touch over eight minutes to process and save those 192 changes. Tim and I worked out an approach which lets us process and save those changes all at once, and we've managed to reduce that processing time down to 30 seconds.

But we're not ready to ship this performance update just yet, because a change this big requires a lot of testing: it's great to have faster sync times, but only if the results are consistent and correct!

I've been running the optimization through its paces against several sample databases, then testing a debug build on my iPhone for the past few days. I found an issue with out-of-order cascading deletes (I'd moved some actions out of a group, then deleted the group, then made more updates to those actions—and consolidating those action updates meant the delete happened first, deleting the actions before they were updated), but since then the only problems I've found are some spurious conflict warnings caused by consolidating updates with inserts without changing the operation type back to insert (now fixed). I think it's about ready to unleash on the rest of Omni, and if that testing goes well we'll start testing it in sneaky peek builds.

[Ken Case]

Originally Posted by Greg Jones

Having said that, I'm also wondering if it involves some bug other than just the number of change files. I've trimmed my database down, synced yesterday, and turned the phone off and on to clear memory. I synced over my network again first thing today without making any changes in either database (other than the automatic changes that occur at midnight) and my sync time was still almost 70 seconds. The stats for the database are 40 projects, 257 actions, and 2 zip files-not exactly a behemoth database compared to some of the other stats I've seen mentioned on the forum.

70 seconds for no changes, ouch! That sounds like a different problem than the one I've been talking about in the last few posts.

The first possibility that comes to mind is that your iPhone was busy compacting its sync history: we could determine this by noting whether the number of zip files after the sync is smaller than the number of zip files before the sync.

Another possibility is that the sync server that you're using was slow for some reason: OmniFocus can only sync as fast as your server responds to its requests.

If you want to try to get to the bottom of this, you could Enable File Manager Debug Logging, then plug your iPhone into your Mac or PC and use the iPhone Configuration Utility to monitor its Console while syncing. You should see a bunch of timestamped log messages from OmniFocus which you can copy and paste into an email message to our support ninjas (omnifocus@omnigroup.com), and those messages should help us figure out exactly what's taking so long.

[Greg Jones]

I'll give file debugging a try tomorrow morning. Thanks Ken.

[dsoyzan]

I am getting the same issues. Typical iPhone sync times of 60~90 seconds. Sometimes this can be up to 5 minutes if I am attempting to sync with a days amendments to the desktop OmniFocus application. I have spoken to the tech support people who were very responsive but, after sending console information, were unable to help me. They suggested I post here.

Let's hope that the performance update mentioned above addresses this issue. Having moved from Things and Toodledo I'm still trying to adapt to a different way of viewing my To Do lists, however getting to a position of syncing typically takes less than 15 seconds would be a massive bonus for me.