Silverlight/WCF service experiencing very slow deserializing on first call

Question

0.00/5 (No votes)

See more:

I have googled and read all similar posts and the answers are not there!

I am using silverlight 5 with a silverlight enabled wcf service, but have tried silverlight 4 and just a regular windows form project with the same results.

All standard default settings using the [knowntype]attribute on the base class for each of my derived classes. I am returning a List<baseclass> consisting of all derived classes.

I have a large number of derived classes (200)which seems to be the issue. My service returns my request quickly, but the proxy takes a long time (10) seconds to deserialize the message. Increasing the number of deirved classes (400+)increases the delay to 60 seconds+. This is only the case on the first call as subsequent calls are deserialized quickly (under 1 second). Apparently the wcf proxy has to do something on the first call to deserialize the data and just reuses it on the subsequent calls. Reloading/refreshing the web page starts the process all over with a significant delay on the first call again.

I have tested it to using the xmlserializer instead of the default datacontractserializer and I do gain a speed bonus on the deserialization, but the initial delay is still there just not as great (but still too much).

WCF is supposed to be a flagship enterprise solution, but so far it stinks for me! I might have to go to remoting, etc if I can't get this resolved.

Does anyone know why the delay is there and does anyone know how to compensate for it?

I have read that with using xmlserializer in windows forms that the first call is slow as it has to build an assembly at runtime to deserialize the data - I suspect the same situation here. svcutil.exe can be used to generate an assembly ahead of time to handle the deserialization and compensate for a first call delay time - silverlight uses slsvcutil.exe which does not have that ability. trying to use regular svcutil results in errors as the silverlight uses different assemblies that regular .Net.

Posted 4-Apr-12 4:13am

YipYipDog

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Eugene Sadovoi · Answer 1 · 2012-04-04T08:59:00

Solution 1

The delay is because of JIT compiling and optimizing your deserialization code. Once it is done it takes no time at all. You may try to play with JIT settings and see if it helps.

You could also redesign your Data so it would not create so many different types.

Posted 4-Apr-12 8:59am

Eugene Sadovoi

Comments

YipYipDog 4-Apr-12 15:07pm

yeah I know I could redesign my data, but whats the point of using OOP if you don't use the power behind inheritance

its a game app where you will have many classes and many derivations of each class:

Location
Province (200)
Sea (20)
Weapons (200)
Ranged
Bow
....
etc
Hand
Siege
Characters
CharacterClasses (20+)

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

where exactly do I find the jit settings

YipYipDog · Answer 2 · 2012-04-09T16:36:00

I have no clue what causes this bug but it would seem logical that it is a threading issue. I did find a work around. Instead of using DataContractSerializer to take apart an object graph and put it back together again I used another serializer like the SilverlightSerializer made by Mike Talbot. His serializer converts your object into a byte array before it is sent through the DCS and then his deserializer rebuilds it. My delays went from 30-60 second delays down to about 2 seconds for a 50K graph consisting of about 5000 objects and 300 derived classes. No need to declare knowntypes with his serializer either - your code is much cleaner.