I think the issue is mainly the scale of this web service. I ran sgen to
generate an XmlSerialization Dll with the option to keep the source - it
ran for so long I thought it was broken - about 5 hours. It generated
365, 200 lines of C# serialization code. There are about 1000
serializable types:
public override System.Xml.Serialization.XmlSerializer
GetSerializer(System.Type type) {
if (type == typeof(global::VimApi.ManagedObjectReference)) return new
ManagedObjectReferenceSerializer();
if (type == typeof(global::VimApi.MethodFault)) return new
MethodFaultSerializer();
followed by 1000 more similar if statements
public override System.Boolean CanSerialize(System.Type type) {
if (type == typeof(global::VimApi.VimService)) return true;
followed by 1000 more similar if statements, all returning true.
public override System.Collections.Hashtable TypedSerializers {
get {
if (typedSerializers == null) {
System.Collections.Hashtable _tmp = new
System.Collections.Hashtable();
_tmp.Add(@"VimApi.VmPoweredOffEvent::", new
VmPoweredOffEventSerializer());
_tmp.Add(@"VimApi.VirtualUSB::", new VirtualUSBSerializer());
_tmp.Add(@"VimApi.VimService:VimApi.UpdateSet
WaitForUpdates(VimApi.ManagedObjectReference, System.String)", new
ArrayOfObjectSerializer852());
followed by 1000 similar lines to populate the hashtable.
There is similar code in a WriteMethods method, a ReadMethods method.
There are about 1000 classes like this:
public sealed class ArrayOfObjectSerializer1010 : XmlSerializer1 {
public override System.Boolean CanDeserialize(System.Xml.XmlReader
xmlReader) {
return
xmlReader.IsStartElement(@"DestroyPropertyFilterInHeaders",
@"urn:vim2");
}
protected override void Serialize(object objectToSerialize,
System.Xml.Serialization.XmlSerializationWriter writer) {
((XmlSerializationWriter1)writer).Write2464_DestroyPropertyFilterInHeade
rs((object[])objectToSerialize);
}
}
and there are thousands of methods.
I wonder if a web service of this scale is capable of optimization. Sgen
and Ngen seem to make no appreciable difference.
Phil Wilson
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill
Sent: Friday, July 14, 2006 9:12 AM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Web Services - Serialization &
Opimizations
>The profile results...are staggering [snip]
I'll say! IIRC, you pre-generated the code (with sgen). Is that what
you profiled? Have you looked at the code (or does it only keep the
generated assembly, not the c# source that was compiled)? I would have
thought that the reflection work would be done by sgen, not by a
constructor in the generated code.
Is this something you could / should optimize via custom serialization?
It likely would be rather painful, given how much code seems to be
needed for this.
I'm curious as to why pre-generated code wouldn't be more optimized.
Can you show us a bit of what it's doing (perhaps with Reflector output
if the source is thrown away)?
At 01:09 PM 7/13/2006, Wilson, Phil D wrote
>The profile results from this web service ctor are staggering. I still
>don't know what's exactly going on, except that it's reflection
related.
>
>
>2.25 million calls to System.Reflection's
>CustomAttribute.CreateCaObject. (about 2 minutes with children)
>
>71 million occurences of Intptr.ToPointer , about 45 seconds (no
>children)
>
>53 million IntPtr..ctor calls, 40 seconds (no children)
>
>39 million RuntimeType.GetTypeHandleInternal calls, 30 seconds (no
>children)
>
>3 million calls to
>System.Reflection.CustomAttribute.FilterCustomAttributeRecord , 6
>minutes with children.
>
>
>Phil Wilson
>
>
>-----Original Message-----
>From: Discussion of advanced .NET topics.
>[mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil
>D
>Sent: Wednesday, July 12, 2006 1:44 PM
>To: [email protected]
>Subject: Re: [ADVANCED-DOTNET] Web Services - Serialization &
>Opimizations
>
>Good thought, but the constructor for the web service is still taking 3
>minutes. In debug mode just before it exits the ctor I see the "Loaded
>'......XmlSerializers.dll' message, so whatever is going on is before
>that. So perhaps it's not a serialization thing after all.
>
>For info, this webservice where the wsdl generates 51k+ lines of C#
>proxy is the VMWare ESX 3.0 webservice that's used to drive VMWare and
>virtual machines.
>
>Phil Wilson
>
>
>-----Original Message-----
>From: Discussion of advanced .NET topics.
>[mailto:[EMAIL PROTECTED] On Behalf Of Richard
>Blewett
>Sent: Wednesday, July 12, 2006 12:49 AM
>To: [email protected]
>Subject: Re: [ADVANCED-DOTNET] Web Services - Serialization &
>Opimizations
>
>You tried running sgen.exe against the types to pre-gen the
>serialization assembly?
>
>Regards
>
>Richard Blewett - DevelopMentor
>
>
>-----Original Message-----
>From: Discussion of advanced .NET topics.
>[mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil
>D
>Sent: 11 July 2006 20:16
>To: [email protected]
>Subject: [ADVANCED-DOTNET] Web Services - Serialization & Opimizations
>
>I'm connecting to a web service with a VS 2005 client. It takes a long
>time (nearly 3 minutes) before the code actually starts doing anything.
>At first I thought this was a JIT thing going on, but I think that
>what's actually happening is that custom assemblies are being created
>to handle the serialization. I know this happens in many serialization
>cases. A profiler run seems to imply this, as well as the fact that
>the last line in the debug output text is something like
"'SimpleClient.exe'
>(Managed): Loaded '-squ_ecj', No symbols loaded." where the name of
>what's loaded is random.
>
>The proxy generated by the WSDL is more than 51k lines of C#.
>
>Assuming I've diagnosed this correctly, and keeping in mind that I
>don't own this web service, is there anything I can do to improve this
>start-up cost? (Ngen doesn't appear to offer anything to deal with
this.
>)
>
>
>Phil Wilson
J. Merrill / Analytical Software Corp
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
