, Richard.Hein wrote

*snip*

LOL, but take it in context ... actually mentioning XSLT/XML probably confuses the issue - it's not really about XML per se.  Users have the option of using JSON as well, and in that case the performance would have degraded slower, but would have still degraded eventually.  Essentially, there is a pipeline, configured via web.config, which determines the components that should process the data.  There was a loop created because the users had configured the first component to process the data, pass that to the 2nd, which passes it to the 1st ... etc....  So, bad coding/configuration was the real culprit, but it also highlighted just how many strings were being created during these processing stages.

Not wanting to be snobbish about it, but an ASP.NET server serving webpages is not a high performance server.

The main speed increase you'll get by switching to JSON from XML has nothing to do with the parsing complexity of the XmlReader or the gen0 collections; but rather will be entirely down to the fact that JSON is smaller on the wire and sending a few extra TCP packets round the globe is going to dwarf any of those minor CPU costs. Hell, a single undelivered TCP packet costs upwards of 40ms to NACK and respond, which is fast enough for my computer to allocate about 33874715 string allocations on my machine, and my machine can do roughly 2800 GC.Collect(3)s in that amount of time too, or 18000 GC.Collect(1)s in that amount of time.

Yes, the GC and string allocates are not free. But on web-servers, the different is negligable. It's like we're arguing about whether the reason the bridge fell down is because of atom vibrations in sodium atoms in the pillars.

The vibrations are there, but that's not why the bridge fell down. It's more likely that you just built the bridge wrong than that the sodium atoms just went all crazy on your bridge.

These discussions always feel like developers going out of their way to blame someone other than themselves for their shoddy code. If they just fix the code (or for heaven's sake, just benchmark it) they'll find out that 99.999999999999999% of the time, the reason their code is slow is because it's slow code that they've written.