3 回答

TA貢獻1850條經驗 獲得超11個贊
數據的版本控制通過屬性進行處理。如果您不擔心版本控制,那么這沒問題。如果是的話,這是一個巨大的問題。
屬性方案的麻煩在于,它在許多瑣碎的情況下(例如添加新屬性)都非常流暢,但是當您嘗試執行將兩個枚舉值替換為不同的新枚舉值(或任何其他枚舉值)時,它會很快崩潰長期持久性數據附帶的常見方案數)。
我可以介紹很多麻煩的細節。最后,如果需要的話,編寫自己的序列化程序非常簡單。

TA貢獻1805條經驗 獲得超10個贊
我同意最后一個答案。性能相當差。最近,我的編碼團隊完成了將模擬從標準C ++轉換為C ++ / CLI的工作。在C ++中,我們有一個手寫的持久性機制,該機制運行良好。我們決定使用序列化機制,而不是重寫舊的持久性機制。
在內存占用量介于1/2和1 Gig之間的大多數舊模擬中,大多數對象具有指向其他對象的指針,并且在運行時具有1000個對象,在一分鐘之內將保留到大約10到15 Meg的二進制文件。從文件還原是可比較的。
使用相同的數據文件(并排運行),C ++ / CLI的運行性能大約是C ++的兩倍,直到我們進行持久性處理(新版本中的序列化)為止,編寫過程需要3到5分鐘,序列化文件的大小約為10到20。序列化文件的大小約為舊文件的5倍?;旧?,我們看到讀取時間增加了19倍,寫入時間增加了5倍。這是不可接受的,我們正在尋找糾正此問題的方法。
在檢查二進制文件時,我發現了一些問題:1.所有類型的類型和程序集數據均以明文形式編寫。這在空間上是無效的。2.每種類型的每個對象/實例都寫入了膨脹的類型/裝配體信息。我們在手保持機制中所做的一件事是寫出了一個已知的類型表。在發現書面類型時,我們在此表中查找了它的存在。如果不存在,則會使用類型info創建一個條目,并分配一個索引。然后,我們將infor類型作為整數傳遞。(類型,數據,類型,數據)此“技巧”將極大地減少大小。這可能需要兩次處理數據,但是可以開發“即時”流程,從而除了將其添加到表中,推送到數據流之外,
我希望重新實現一些核心序列化以這種方式對其進行優化,但是,可惜這些類都是密封的!我們可能仍未找到捷徑。
- 3 回答
- 0 關注
- 1055 瀏覽
添加回答
舉報