Marcus wrote:
Hameed wrote:
How would I achieve this. Could you please elaborate!
You have to parse the XML manually and create the object graph yourself. The advantage of this is that you already know the structure of the schema and hence what to expect next when parsing the tree. You can therefore optimize the instantiation of new objects as you traverse the XML tree.
Be careful however as you will incurr an addition maintenance cost as you are effectively hardcoding the schema in deserializtion code.
I have seen this method used in some high traffic SOA implementation in order to increase message throughput. They achieved a 50% increase in throught by eliminating the generic XmlSerializer.
Deserializing entities isn't using the XmlSerializer but a routine inside the entitycollection/entity. The XmlSerializer can't deal with cyclic references and interface based types which is the reason why the custom xml deserializer code is there.
The Xmlserializer generates C# code which is in fact containing that hard-coded schema reading code you mentioned
.
The compact XML reader is quite straight forward though, it only uses a collection creating using reflection when it has to, but this might take a while on the CF, I'm not sure (which is the hard part, if you're unsure what the bottleneck is, it's impossible to optimize). So
What I wondered was: if the deserialization of a single collection of entities is quite fast (and on the emulator here it is ok) but a graph isn't, it has something to do with the graph structure, which might cause problems, so if a single entity with a 2 entity collection inside already takes ages, it;s definitely somewhere in the graph reconstruction code which is then somewhat easier to track down.