數組序列化性能問題

在我的Windows Mobile（.NET Compact Framework）應用程序中，我使用大數組來存儲應用程序的主數據。這是潛在數百個對象的數據集。每個對象都有大約10個屬性和兩個自己的數組，每個對象都有大約25個其他對象，每個對象都有大約5個屬性。數組序列化性能問題

要將此陣列保存在移動設備上，我只需序列化整個陣列。這在大多數情況下都很有效，而且非常非常簡單。

但是在我們的測試案例中，我們一直只使用少數幾個對象，最多隻能使用50到75個。但是我們的客戶已經有用戶擁有數百個對象的情況，最多可達1000個。在這些情況下，序列化很慢，可能需要一分鐘。

實際的問題是保存整個數組時，大多數情況下只有幾個對象實際發生了變化。所以基本流程是這樣的：

從存儲裝載整個數組，比如400個對象;
更改1個對象的一些屬性;
將整個數組保存回存儲空間，完整的400個對象;
更改同一對象的更多屬性;
再次保存
更改最終屬性;
再次保存;
同樣的，任何後續對象...

如果沒有發生儲蓄往往這不會是一個問題正常，但在幾個中間步驟的數據被保存。這是爲了確保所有的數據都是持久的，並且不會發生數據丟失（例如電池耗盡時）。

我該如何解決這個問題？

來源

2010-10-01 pbean

我對Windows Mobile並不熟悉，但對於通常從設備傳輸/傳出設備的「移動設備」來說，性能確實非常重要。我會調整你的代碼，使你只發送/接收改變的數據。例如在你的例子中，一次只發送「幾個屬性」。（請記住，數據傳輸通常會花費最終用戶$ money - 因此您希望它儘可能小） – scunliffe 2010-10-01 10:25:46

數據傳輸沒有問題。傳輸速度足夠快（通常在通訊座使用Wifi或「直接」連接）。但是序列化到內部（永久）存儲器（閃存或SD卡或其他任何東西）是很慢的。 – pbean 2010-10-01 10:45:41

好的，但我認爲這個問題再次涉及到多少數據被修改。我只會根據需要更新內部數據結構......例如更新索引「X」處的子數組以添加這3個項目。不要嘗試將整個結構發送回設備並重新構建整個數據結構。 – scunliffe 2010-10-01 11:56:04

所以要清楚，le't確保我理解您的方案：

你有什麼是某種形式的序列化數組的（你沒有規定的格式爲XML，二進制或其他）作爲你的數據存儲？
如果一個屬性發生變化，即使有1000個具有子對象的對象，您也會重寫整個數組？
而你正在寫Flash，不只是RAM？
而對於一個完整的「保存」你幾次寫操作？
由於某種原因，您發現這樣慢，數據集越大，速度越慢？

答案其實很簡單。這是基於你如何做這件事的完全預期的行爲。爲什麼要將這種機制用於數據存儲，特別是對於大型且頻繁更改的項目？這是一個糟糕的設計決定的典型例子。當一個屬性發生變化時，你應該改變商店中的屬性，而序列化數組根本不適合這個。

您應該使用實際的數據庫引擎，不管它是RDBMS還是對象數據庫，但是正在實現的方式不會寫入存儲介質。如果您需要將數據作爲數據傳輸到PC /服務器，那很好 - 創建一種機制從存儲中提取並將其放入數組中。

來源

2010-10-01 13:13:59 ctacke

我並不感到驚訝，它很慢，我認爲這是合乎邏輯的，但我想找到一個解決方案（可能通過使用另一種方法來保存）。我多次保存以防數據丟失（如我所述，例如電池在運行時死機）。我使用序列化，因爲它很容易（只有一種方法）。 RDBMS非常複雜。正如我所說這是一個移動平臺，所以我不能只是把MySQL或PostgreSQL放在那裏。感謝批評我目前的實施，並沒有給出我的實際問題的具體答案。 – pbean 2010-10-01 14:07:28

我該如何給出一個具體的解決方案？實現是不明確的，所以我給出了一個含糊不清的「使用數據存儲而不是序列化數組」的答案。 RDBMS並不是那麼複雜，特別是如果您使用ORM，並且少數（如SQL Compact和SQLite）可用於設備。同樣，許多對象數據庫（如db4o和Perst）也同樣簡單。我無法真正地告訴你使用哪個，因爲我對你的應用程序，你的經驗水平或你的要求一無所知。 – ctacke 2010-10-01 14:34:14

數組序列化性能問題

回答

相關問題