今天我终于设法运行客户端（Windows移动设备）-WCF - SQL服务器2008年同步（后许多问题，主要是MS部分）Microsoft Sync for Ado.Net - 效率如何提高？
我做了测试。对于24 000条记录，快照的平均时间大约需要1分20秒。我已经下载了针对ADO.NET的Microsoft Sync修复程序。
我也发现50秒后数据库文件终于开始增长，大约需要25秒。
框架在前50秒内做了什么？加载和序列化数据？
在某个页面上，我找到了关于代理序列化的文章，它可以减少传输的数据量。
你知道同步过程是否可以从中受益？ （我的意思是修补程序后用于Ado.net的MS Sync）
有什么我可以做的，以加快进程？在我看来1:24为24000两倍太多...
存在与设备同步框架两大问题：
您提到的修复程序地址＃3尽可能最好，因此您可以在其中完成任何其他操作。
号码2是同步框架的一部分，对此恐怕没有什么可以做的。
至于＃1，这是大约50秒（大概是30左右）的地方：当客户端收到数据集时，它必须反序列化整个数据流（数据流由极端详细的XML），然后才能开始处理。对于大型数据集（超过10,000行），这可能需要很长时间，并且一旦可用堆内存最大化，最终可能（甚至最终）会导致内存紧缩情况。
您引用的序列化替代方法将大大减少正在交换的响应流的大小（在我的测试中，在某些情况下它几乎减小了90％）。这肯定会在一定程度上缩短响应时间，特别是当网络连接吞吐量有限时。然而，在一天结束的时候，你无法避开这样一个事实：在开始客户端处理之前，必须将该流反序列化为DataSet。
所有这一切说：是的，替代序列化方法会降低传输的数据量，你就可能实现一些改善，但多少将取决于多种因素，如：
希望这有助于！
如果您使用的是SyncFx 2.1库（SynchOrchestrator不SyncAgent），那么SyncFx将已经使用DataSet代理序列化 - 它是内置。
为了避免数据集相关外的内存问题，你可以看看配料想方设法限制，可以每同步发送的记录数。它可以在一定程度上用一组SyncFx库来完成，但是对于2.1库比1.0库更确定一些。
*确定性： 2.1库允许您指定的最大字节数， SyncFx会自动在最后一个完整一行是 限制内切配合东西了。随着1.0库，我相信，到 唯一的办法做配料是指定一个最大行数，和希望（或仔细算算），数据 不超过你想达到的极限。
三件事情发生时，你同步： 1.它需要枚举已发生变化
就需要把它发送到目的地
需要应用它
枚举，数据库的规模将有很大的影响。即使没有变化，您也会为此检查产生一些性能损失。
的项目＃2，数据集序列化的瓶颈。您可以选择使用数据集替代品甚至是压缩，但是您可以使用数据集替代品并进行压缩，并且您可能看不到大规模的性能改进。
见：Sync Framework WCF-based Synchronization for Offline scenario – Using custom dataset serialization
的项目1和2，你可以申请你像synching只有你通过滤波，调谐指数等需要行的数据库做同样的性能调整...
后所有，同步Fx应用程序就像任何其他数据库应用程序。
可同步过程真的会导致“内存不足”的设备问题？说实话，我认为这个框架“准备好”了将这些大数据转移到sql ce中（或者我可能天真地认为如此..），以及我原来的同步手工制作的过程，由于我遇到的反序列化问题，进行了几次调用以获取部分数据......顺便说一句，插入到sql ce中的“直接模式”非常快，还有在codeplex上批量插入类似乎是超快... – John
是的，它肯定会导致OOM条件。取决于行的数量和每行的宽度等，但在某些时候，你会打它。请记住，每个进程分配的最大32MB的工作。此外，根据您使用的操作系统（WM6.1及更高版本有所缓解），大量内存被所需的系统库使用。 – pdriegen
呃有时候我真的认为如果我在服务器端准备一个带有更大表格的sdf文件并将其上传到移动设备上会更好....不管怎样，感谢您的帮助！ – John