Frans Bouma wrote: > Consider an object which is serializable to XML using the > SOAP formatter. the XmlSerializer is first serializing the > object to XML. This is done using an utterly slow, FILE > based approach.
Where does this persistent myth spring from? I suspect it is because someone who didn't understand what they were doing ran a naïve test once and published something misleading about the results. More importantly, why do people who should know better keep repeating the myth? But there's no need to go blindly repeating such technical inaccuracy. And it would indeed be somewhat shocking if the XmlSerializer always went via the filesystem, so it amazes me that anyone repeats such a claim without first trying it themselves to find out if it's really true. It's pretty trivial to construct your own test to find out whether this claim is accurate. It takes less than 5 minutes to write, and such a test will prove that this claim about the serialization process performed by XmlSerializer being FILE based is just plain wrong. It's true that the first time you fire up an XmlSerializer in a process, there's some disk activity. But only the first time. If you observe what's going on with FILEMON, you'll see that the first time you ask for an XmlSerializer for a particular type, the C# compiler gets fired up. But once you've asked for the XmlSerializer for that type, you can ask for it as many times again as you like, and it you'll not see any disk activity at all - it just reuses what it built earlier. (And if you care about performance, presumably you were planning to serialize and/or deserialize more than just once, right?) Nor will you see any disk activity when you ask it to serialize and deserialize objects for you. (Unless you serialize via FileStreams of course...) So there's nothing intrinsically file-bound about XmlSerializer once its up and running as far as I can tell. (If you have evidence to suggest otherwise I'd be interested to see it though.) Of course that doesn't mean ASP.NET isn't doing something bizarre, but that wasn't what you said. Is that what you meant - is it really ASP.NET that does stuff with files (and not the XmlSerializer, as you claimed)? If so, do you have any evidence to back that up? And aside from that one detail, what about your more general claim that XmlSerializer is slower than SoapFormatter? There's a fairly well-known article on MSDN that talks about the relative performance of various styles of .NET remoting vs .asmx web services: http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch14.asp Notice that the throughput and response time of SOAP over remoting is substantially *worse* than .asmx for all user loads when hosting in IIS. This is further reason to be suspicious of your claim that XmlSerializer is slower than the SOAP binary formatter. Apparently XmlSerializer is faster here. The only situation in which the SOAP binary formatter can do better (and even then, only some of the time) is if you use the TCP channel and don't host in IIS. And yes, those two things are have performance benefits, but again it has precisely nothing to do with the XmlSerializer. (In other words, SoapFormatter only looks better if you stack the odds in its favour first.) For high loads, the XmlSerializer-based .asmx appears to achieve better throughput and response times than the SoapFormatter-based remoting setups when the host process and channel types are equivalent. Indeed, even with the disadvantages of using being in IIS (which would be likely to be less of an issue in Windows 2003; these tests were performed in 2002), and using HTTP, the XmlSerializer still often wins. (And this includes the disadvantage imposed by the overhead of the SOAP envelope.) (Note that in one of the tests, they required some extra configuration to the buffering handling in ASP.NET - the out-of-the-box .asmx performance was, in this one test, slower than the SoapFormatter setup. But again, since this problem could be fixed at the ASP.NET level, it seems pretty clear that XmlSerializer isn't the culprit.) Only two of the possible remoting configurations consistently outperform the .asmx web service implementation according to those tests. They are the TCP Channel + Binary Formatter, and the HTTP Channel + Binary Formatter, both running outside of IIS. (And that latter is extremely close. It's only the TCP+Binary+not-IIS option that gives you a really substantial benefit.) Have you run other tests that contradict these (fairly widely reported) tests? Or are you just describing what you think should be fastest, based on some internal mental model of yours? If there is other evidence around that tells a different story, then again, I'd love to see it. > However if you just have an application sitting on 2 1U boxes > in the same 19" rack, why on earth would you set up the > communication between the processes on both boxes via xml? There's a very good reason not to use .NET remoting in such a setup. (That's not an argument in favour of XML per se, of course. However, web services don't suffer from the problem in question.) .NET remoting requires both ends to share type information. This entails a degree of coupling between your systems that is likely to be highly undesirable. There's also a good reason to host in IIS today, which is that it's the only supported mechanism for getting integrated authentication. You can use that on both .NET remoting and .asmx of course, but remember that once you host in IIS, you've already lost the lion's share of the performance advantage .NET remoting could otherwise have given you. It's true that if you use the binary formatter and TCP channel, .NET remoting can offer better performance, especially if you are able to host outside of IIS. But it's not as big a difference as some make out. Moreover, you are increasing the coupling in your system, so you really have to ask yourself whether that last ounce of performance is more important to you. Sometimes it is. But you seem to be saying that web services are always the wrong choice, and I really can't agree with that. -- Ian Griffiths - DevelopMentor (RSS: http://www.interact-sw.co.uk/iangblog/rss2.0 ) =================================== This list is hosted by DevelopMentor® http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
