Question

Background for understanding the question

I’m currently designing a simple, light-weight (application-specific) message-based API in C# 4.0. The majority of the messages will leave the .NET/Silverlight stack, thus they get serialized as a XML stream. Some messages are also send/received to local components, hence there is no reason for serialization.

Currently, there is a simple data abstraction layer designed for that API, which contains the content of the message. This data abstraction layer is supposed to be soley used for that purpose.

Now, there is the challenge that, especially during initialization of the application, there are some very big messages, which are received by other systems, thus the xml stream is pretty heavy-weight (several thousand of xml elements). That would mean there several thousand instance of that data abstract layer objects are generated, the message is processed and then the whole data instances are removed.

Question

My question would be: Is linq-to-xml quite good concerning memory consumption/performance so there is no need for a separate data abstraction layer?
My understanding is that linq-to-xml renders only the content if the content is written to a stream.

Thanks for giving feedback.

Answer 1

LINQ to XML does parse your document in a lazy way, but it does build a complete graph of objects into memory, and it creates a lot of object in memory. It has a great API but is certainly not light-weight. Please do measure performance to see if the performance of LINQ to XML suites your application performance requirements.