This post originated from an RSS feed registered with .NET Buzz
by Scott Hanselman.
Original Post: XmlSerializers Part II: Am I Insane?
Feed Title: Scott Hanselman's ComputerZen.com
Feed URL: http://radio-weblogs.com/0106747/rss.xml
Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios.
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.
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...
Previous Topic
