XmlSerializers Part II: Am I Insane?
Simon Fell's comment regarding my XmlSerializer quandry got me thinking. He said the obvious:
Only creating the first instance for a particular type is expensive after the first instance there is no overhead.
However, I SWEAR I saw different performance under 1.0. Has something changed in 1.1? Time to pull out a copy of .NET 1.0 and run my tests again.
Running with .NET runtime version 1.1.4322.573.
Took 00:00:00.4531163 ms to create 10000 serializers without pre-initializing.
Took 00:00:00.2499952 ms to create the first serializer.
Took 00:00:00.0312494 ms to create 10000 serializers after pre-initializing the first one.
So, perhaps my whole caching XmlSerializerFactory was sillyness, and I was trying to work around some odd behavior that existed in 1.0. OR, some behavior that existed purely as an artifact of my previous app.
BUT: Joseph Cooney says:
The XmlSerializer has a number of constructors. If you use any of the constructors other than the one that takes a type (for example specify a type and a default namespace) then a new temporary assembly is created EVERY TIME you create a serializer, rather than only once. I can post some code to demonstrate this if you like.
Maybe that's it, and it would make sense. The basic constructors would allow the generated type & assembly to hang out. The others would mean that namespace passed in could come from anywhere (it could be highly variable, while the type wouldn't be)...so, they'd just punt and make a new assembly each time.
Either way, this GOOF goes to show - measure. Don't assume like I did. I'm off to figure this out...
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Comments are closed.
So no, you're not (entirely) crazy.