CLR keeps on probing for XmlSerializers assembly

[Vagif Abilov]

I noticed that components that use XmlSerializer class cause CLR to probe
for XmlSerializers assembly. Is this default behavior, i.e. whenever
component try to serialize/deserialize one of its classes, CLR will search
for pre-compiled serializer? If so, can I simply use SGEN tool to generate
such assembly and CLR will automatically use it? And will it really give a
significant performance advantage?

Thanks in advance
Vagif Abilov
Oslo Norway

 

[Ben Voigt]

I noticed that components that use XmlSerializer class cause CLR to probe
for XmlSerializers assembly. Is this default behavior, i.e. whenever
component try to serialize/deserialize one of its classes, CLR will search
for pre-compiled serializer? If so, can I simply use SGEN tool to generate
such assembly and CLR will automatically use it? And will it really give a
significant performance advantage?

The cost of generating the serializer is substantial (since Reflection.Emit
is quite heavy-duty), however the ongoing performance should be equal since
I believe it's the same code used for pre-compiling and on-the-fly, and that
the on-the-fly serialization assembly is cached for the lifetime of the
appdomain.

 

[Vagif Abilov]

Thanks, so this means once generated it will be kept as long as AppDomain
lives. Then we will probably afford online generation.

Vagif