Even using sgen on my service class still results in agonizingly slow constructor

So I'm trying to speed up our applications startup times -- and I've identified a major bottleneck to work on. Each of our webservice client classes takes forever and a day to instantiate. Some investigation revealed this is entirely due to the SoapHttpClientProtocol running GenerateXMLMappings. I started searching for information on this and fo开发者_开发问答und this SO post Slow SoapHttpClientProtocol constructor

I was ready to sound the trumpets since my issues mirrored what was talked about there to the letter. I went through every step listed in the first post to use sgen to pre-generate a serializer dll, and then removed the various tags from the code and built that into a normal dll which I referenced in the applciation as a normal reference (as opposed to a web reference). However after all this, I don't see any difference when profiling the application. Tons of time is still soaked up doing GenerateXMLMappings as part of the SoapHttpClientProtocol constructor.

I have verified that it is in fact using my custom webservice client dll. I have also verified that it is at least looking for the XmlSerializers dll (if I do not include the file I can see a filenotfound is spit up about it).

Does anyone have detailed info about how the SoapHttpClientProtocol constructor decides what it needs to do? This is a really frustrating problem because the whole process seems to be blackboxed with no good way to see what is actually going on internally.

Thanks in advance for any help -- I'm completely against a wall on this one.

I hit this every so often. I'll be happy to guess, but guesses are usually wrong.

To find what the problem really is I just run the app under the IDE and pause it a few times while it's being slow, to see what it's doing. That's this technique.

OK, here are the guesses, which I've seen but for you are probably wrong.

1. Fetching strings from resources during load.
2. Notifications gone mad while building data structure.
3. Initializing 3rd-party grids/controls, even with empty data.
4. Parsing/Writing XML more than you thought.
5. Zipping/Unzipping more than you thought.