I have an application written fully with DO 3.9 using offline layer on client. The problem I have is a very time-consuming ClientSideCache.RegisterDomain() call when client app starts. This call lasts about 15-20 seconds and makes my users very unhappy when they runs the app. I have traced the problem to Deserialize() call reading ObjectModel from client side cache folder. Frankly speaking, application indeed has a big object model (about 230 persistent types and all together about 10.000 fields), but still somehow I feel - loading time can be better. The size of ObjectModel.bin file on disk is about 20Mb. Is there something I can do about it? Thanx in advance.

asked Nov 22 '10 at 17:47

murlex's gravatar image



Unfortunatelly it is quite difficult to identify certain issue by the short description. The reasons can be very different strarting from IDeserializationCallback interface usage on ObjectModel.Model class to unefficient implementation of deserialization constructor for some of model fields.

Is it possible to get problematic model assembly for profiling purposes?

(Nov 23 '10 at 04:56) Alex Ustinov Alex%20Ustinov's gravatar image

http://close-to-heart.com/xtensive/longTimeLoadDemo.rar Here is the file set demonstrating the problem I've described. Thank you in advance. Please, read the text file in the archive for usage instructions.

(Nov 23 '10 at 13:37) murlex murlex's gravatar image

I've found that most of a time application spends in BinaryFormatter.Deserialize method(as expected) but calls to our deserialization constructors take only few seconds from whole deserialization cycle. Rest of a time BinaryFormatter performs it's internal routines.

The only thing I can change is to eliminate IDeserializationCallback implementation at ObjectModel.Model class. This would decrease BinaryFormatter's load. I'll try this tomorrow morning.

(Nov 24 '10 at 10:48) Alex Ustinov Alex%20Ustinov's gravatar image

One Answer:


Unfortunatelly it seems impossible to speedup deserialization of the ObjectModel.Model class for now. As I've discovered IDeserializationCallback presence does not impact overall performance: Most of the time BinaryFormatter spends populating properties by reflection.

I suppose the possible option would be implementing some kind of handmade serialization/deserialization routines. Such routines would not to use reflection consequently they would be faster. But this option is not a fix. It is significant redesign and consequently is too time consumable and too expensive.

answered Nov 25 '10 at 03:29

Alex%20Ustinov's gravatar image

Alex Ustinov

Yes, I see. Thank you anyway. May you have some other recommendations on this issue?

(Nov 28 '10 at 09:59) murlex murlex's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA