The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus for iPhone
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Still Long Sync on iPhone... Thread Tools Search this Thread Display Modes
I ran the debug routine that Ken suggested above, submitted the results to support, and I heard back from one of the ninjas that indicated the info was useful. Perhaps we'll see an update soon.
 
Quote:
Originally Posted by Greg Jones View Post
I ran the debug routine that Ken suggested above, submitted the results to support, and I heard back from one of the ninjas that indicated the info was useful. Perhaps we'll see an update soon.
It's really puzzling that some people see this regularly while others don't see it at all.

As I mentioned earlier, I have a fairly large number of actions/projects (~2000 actions, ~325 projects), two clients, and usually around 50-100 zip files. I almost never see a MobileMe sync take longer than 30 seconds, and most are just 3-10 seconds. I have no complaints about sync performance whatsoever.

What's different between our systems? I mean, if the problem is just this inefficiency mentioned by Ken, shouldn't we all be seeing slower sync times? The impact on mine seems almost negligible.

Is it number of clients? I have just two.

Or is it database file size or number of attachments? Mine is about 400-500K and no embedded attachments.

Anyway, I hope the problem gets ironed out soon because snappy sync times are really nice.

-Dennis
 
Quote:
Originally Posted by Toadling View Post
What's different between our systems? I mean, if the problem is just this inefficiency mentioned by Ken, shouldn't we all be seeing slower sync times? The impact on mine seems almost negligible.
I think so too. Our databases must be different in some way. (Then again, why is there no performance issue when syncing the Desktop client?)

Quote:
Originally Posted by Toadling View Post
Is it number of clients? I have just two.
Same here (1 Desktop, 1 iPhone).

Quote:
Originally Posted by Toadling View Post
Or is it database file size or number of attachments? Mine is about 400-500K and no embedded attachments.
I currently have one attachment (1.0 kb). (And I think sync was equally slow when I didn't have any.)

My database now weights 692 kb. (When I checked the size on the Webdav server it said 332.86 GB (in the Finder), but I guess that's Snow Leopard's fault.) And it contains around 500 actions. (In 199 ZIP files.)

BTW, I have used some special characters (like '<', '+', '|', etc.), and I noticed that (after syncing?) '> <' becomes '><'.
 
Quote:
Originally Posted by Toadling View Post
It's really puzzling that some people see this regularly while others don't see it at all.
I don't why either, but my current system could not be more vanilla as to the sync configuration-1 Mac, 1 iPhone, no Dropbox/3rd party interaction, and syncing with MobileMe. I trimmed my database considerably, using both the Archive function and culling out the 'Someday' projects that might as well be 'Noneday'. If my list of projects, actions, and attachments were any smaller, I might as well keep them on a single sheet of paper.

The sync times I have reported here are when I am syncing over Wi-Fi. The times are so bad over Edge that I don't even bother timing them as it's just unusable. I have to turn auto-sync off, and then I don't always remember to turn it back on when I am back on Wi-Fi again. I really need this to be fixed, but if not I'm going to put in a feature request to have a preference to only sync while on Wi-Fi, similar to the preference that Evernote for iPhone has.

It's curious, but it's not the first time something similar has happened with OmniFocus iPhone. If you recall the bug in (I believe) 1.5.2 that caused a crash when exiting the location screen? I never could reproduce that on my iPhone and I tried.
 
I also sync over wifi. And it always takes more than 30 seconds, most of the time around 100. (I have now ca. 600 actions.)

Those are the times for mydisk.se. When I was using swissdisk.com it took even longer. When I synced after just having synced it would still take about 45 seconds. (The progress bar would appear after 30 seconds--directly to full progress. So I guess there were some difficulties connecting to the server.)

But as I understand it, the WebDAV server is not the issue here, since some MobileMe users expirience this "bug" and others don't. (Is there only one port over which you can conntect to the MobileMe WebDAV server?)
 
I think this must be an interaction of the bug Ken wrote about and our usage patterns. Recall that the bug was OF consolidating the database after processing each transaction, instead of consolidating once at the end. I tend to do a lot of rearranging of my database between syncs (i.e., moving actions around, changing action groups). I also tend to check off lots of items during the course of the day, because I use templates that break actions down into many steps. Finally, I have a deep hierarchy of folders, projects, and action groups. The majority of my actions are in triply nested action groups, within projects that is doubly nested in folders.

My suspicion is that the deeper hierarchy makes the consolidation step take longer.

Dennis, do you tend to have complex project and action group hierarchies, or is your system flatter?

Greg and ricot, does your usage match any pieces of mine?

Cheers,

Curt
__________________
Cheers,

Curt
 
Quote:
Originally Posted by ricot View Post
I also sync over wifi. And it always takes more than 30 seconds, most of the time around 100. (I have now ca. 600 actions.)

Those are the times for mydisk.se. When I was using swissdisk.com it took even longer. When I synced after just having synced it would still take about 45 seconds. (The progress bar would appear after 30 seconds--directly to full progress. So I guess there were some difficulties connecting to the server.)

But as I understand it, the WebDAV server is not the issue here, since some MobileMe users expirience this "bug" and others don't. (Is there only one port over which you can conntect to the MobileMe WebDAV server?)
I would hesitate to draw any conclusions about whether the server is part of the problem without seeing a timestamped transaction log (such as you can get with the File Manager debug mentioned earlier). Some people could be experiencing slow syncing because of a slow-to-respond WebDAV server (there's a lot of back and forth chatter between client and server), others might be seeing reasonable performance on the interaction with the server, but then a very long time spent processing the data due to the bug Ken mentioned (or a perhaps yet undiscovered bug), some might be lucky enough to have a combination of problems, and we have the uncontrolled variables of database size/structure and iPhone/iPod and network performance. Without seeing where the time is being spent, there are too many moving parts here, and one could easily come to an erroneous but seemingly logical conclusion that simply delays the process of getting everyone's sync times to a reasonable value.
 
Quote:
Originally Posted by curt.clifton View Post
Dennis, do you tend to have complex project and action group hierarchies, or is your system flatter?
@Curt: Most of my hierarchies are only 1 or 2 levels deep, and none are more than 3 levels deep.

Quote:
Originally Posted by whpalmer4 View Post
Without seeing where the time is being spent, there are too many moving parts here, and one could easily come to an erroneous but seemingly logical conclusion that simply delays the process of getting everyone's sync times to a reasonable value.
@Bill: That's an excellent point that really underscores the complexities involved here. Without more information, it's hard to come to any kind of meaningful conclusion. Hopefully, OG has been able to collect the data they need to diagnose this issue.

-Dennis
 
Quote:
Originally Posted by curt.clifton View Post
Greg and ricot, does your usage match any pieces of mine?
Some days I will have a high amount of activity in the database, as do you, but I typically sync multiple times a day so there is seldom a mass amount of changes during any one sync. One of the worst sync times I had came one morning, when I had not made any changes from the last sync. The only thing different in the database was that 3 tasks had become available after midnight, so the status of those tasks changed.

My database hierarchy is very flat. I have 8 Area folders and all projects in these areas have same-level tasks. I moved away from nested projects/action groups a long time ago as I now prefer to break up complex projects into their own stand-alone projects.
 
Quote:
Originally Posted by curt.clifton View Post
Greg and ricot, does your usage match any pieces of mine?
Mine matches any piece of yours. Deep hierarchy, a lot of rearranging, and I add and delete a lot of items. But I sync quite often, and when I have only added three inbox items since last sync it still takes >30 seconds.


Quote:
Originally Posted by whpalmer4 View Post
I would hesitate to draw any conclusions about whether the server is part of the problem without seeing a timestamped transaction log (such as you can get with the File Manager debug mentioned earlier).
If the server would be part of the problem how could the Desktop version sync fast? (I haven't heard anyone report slow Desktop syncs.)
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
oFocus size? (long load&sync times) santra OmniFocus Syncing 3 2008-08-26 11:11 AM


All times are GMT -8. The time now is 02:01 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.