Interesting Observation - Sync time comparison of Related VC's versus No Related VC's

[WillowMobileSys]

I have been working to reduce Sync time in an app having a Parent table plus 2 fairly good sized Child tables. 

• Parent - 1013 rows 
• Child 1 - 15, 310 associated rows
• Child 2 - 12,774 associated rows

One idea I had was to eliminate the Child Related VC's by defining the Parent column in each Child table as Enum/Ref...which prevents the Related VC's from being inserted.   

However, after making changes, I found that the Sync time wasn't affected all that much.  I had been experiencing Sync times in the range of 12-18 seconds.  Eliminating the VC's seems to only save about 2 seconds off that range of Sync time - which was a complete surprise to me as the Sync time devoted to these 2 Related VC columns alone was in the neighborhood of 8-10 seconds.

I have gone back and forth at least 6 times comparing a series of app Sync's after each change to the column definitions.  The results are consistently the same - eliminating the Related VC's is faster but only by about a couple of seconds.  Below is a table comparing two Sync tests.

The Good News is that there DOES seems to be some optimizations happening to minimize 
the impact that these Related VC's could have on Sync times!

The conclusion...

Since Sync times can very widely anyway, it is not worth degrading user experience simply to save a couple seconds on Sync time.  Maybe, if the Child tables were multiple tens of thousands of rows  or larger and not frequently visited, it might make sense then to eliminate the Related VC's in favor of another way to access the Child rows.

---------------------------------------------------

Below are two comparative examples.  The overall Sync time in both was 13.4+ seconds.  Comparing only the portions of time related to the Parent/Child tables there only a Savings of 2+ seconds by eliminating the Related VC's.  All tests had this same basic result.

Sync (s)	Table	Rows Read	Read Time (s)	Related VC's	Calc Time (s)	Total (s)
13.4	Parent	1013	1.2	0	0	1.2
	Child 1	15,310	4.9	0	0	4.9
	Child 2	12,774	2.31	0	0	2.31
						8.41
------	-------	--------	-----------	-------------	------------	---------
13.49	Parent	1013	1.16			1.16
				Child 1	4.26	4.26
				Child 2	2.21	2.21
	Child 1	15,310	1.73			1.73
	Child 2	12,774	1.14			1.14
						10.5

[Marc_Dillon]

Thanks for sharing some real data. I remember in one of those long threads years ago about optimizations, Praveen himself said not to worry about REF_ROWS.

Although I can say that a couple years back, I brought an almost painfully long-syncing app to within a more comfortable sync time just by converting most Refs to Enum-Refs, thus eliminating the REF_ROWS. There were a lot though, so the single second per table really stacked up. That app was terribly built anyways, so the point kind of still stands; if you're removing REF_ROWS to save on sync time, there are probably lots of other and better optimizations that you should be doing instead. Unless there's no other option.