views:

481

answers:

2

So I took a specific hot-spot from a very large web application, that does lot of XML processing (adding nodes, adding attributes to nodes based on some logic), then created a standalone test to mock the same situation using Linq to XML (as opposed to XmlDocument)

There was 2 to 10 times performance improvement in the standalone test comparing Linq To Xml with using XmlDocument.

Now the same change was applied to the web application, but the improvement didn't show up for both Performance and Memory - at all, it came out to be the almost the same as using XmlDocument. All other factors/code were same before and after, so it was made sure there were no other changes.

Apart from Concurrency - web requests, I am not sure why this would happen.

Any suggestions would be appreciated. Has anyone else come across similar behaviors?

[Tests were run on Windows XP and Windows Server 2003 running .Net framework 3.5]

Update: Also I've to mention there is no disk IO involved in here. The XML is constructed on the fly in-memory, and is not written back to a file or anything. It's used only to be able to pass to another external system, which expects it. The external system is unchanged before and after.

+1  A: 

You need to compare apples to apples.

  • Don't compare Web+XmlDoc to StandAlone+LinqXml.
  • Do compare StandAlone+XmlDoc to StandAlone+LinqXml.
David B
I think he already did StandAlone+XmlDoc to StandAlone+LinqXml comparison and got "2 to 10 times performance improvement." Then did Web+XmlDoc to Web+LinqXml comparison and didn't see any improvement. So now, why is StandAlone+LinqXml better than Web+LinqXml?
Dennis Palmer
Yes I did, and that's how I figured the improvement was 2 to 10 times
Vin
A: 

My guess would be that the disk access is the main bottleneck for the web server approach and so any gains in the way the XML is parsed are overshadowed by the disk access. However, this is a guess.

Jeff Yates