Speed issues with 2.0 app referencing 1.1 assemblies

[Guest]

I am experiencing a lot of speed issues on initial app loads where we are
referencing 3rd party 1.1 assemblies from 2.0 code.

Those 1.1 assemblies reference things like System.Windows.Forms (totally
unnecessarily I might add).

I'm assuming our memory footprint will practically double by re-loading the
System, System.Web, System.Windows.Forms assemblies.

This also causes a significant bottleneck. For example:

Object A has a static method called Load().
A.Load() calls another static method called Read().
A.Read() references a 1.1 assembly that in turn references System.Web,
System.Windows.Forms, and a few other namespaces.
A.Load() takes sub-second to run, but when it calls A.Read(), before the
first line of code in A.Read() executes, 12 seconds passes.

Under 1.1 our entire app took less than 5 seconds to start up and render
it's first page. Now some directories take over 60 seconds to load the first
time.

We are working to update all of these 3rd party controls with 2.0 versions,
but some might not be available. Is this the expected behaviour?

We are using the Web Application Projects offered in VS.Net 2005 SP1.

 

[Steven Cheng[MSFT]]

Hello Stefan,

From your description, I understand you have an ASP.NET application
recently upgrade from 1.X to 2.0 framework. It works correctly, but has
experienced slow performance issue, and you found that the problem seems
related to a 3rd party assembly which is still compiled under .net
framework 1.1.

Regarding on the this issue, I think the problem should be coupled with the
3rd party component's internal code logic also. For .net framework runtime(
no matter ASP.NET or normal .net application), it can only load a single
set of framework assemblies in a given process. That means, if your
application is running under .net framework 2.0, all those system
assemblies (such as mscorlib.dll, System.dll, System.Web...... ) are all
the .net 2.0 ones. Even if some certain referenced assembly is referencing
..net framework 1.1, the runtime will not load another copy of the .net
framework 1.1 system assemblies.

In Visual Studio 2005, you can start debugging your ASP.NET application and
in the debug output windows, you can find all those loaded assemblies at
startup time. Their version are comform to the main application's runtime
version. I have performed some test in my local environment and confirm
this behavior, and some simple class library component(target 1.1 framework
version) seems not able to repro such slow performance behavior.

Currently, If you have detailed info about that 3rd party component's
internal code logic, you can try creating a test dll to simulate its code
logic and test in your web application. You can build such a test dll under
both VS 2003/.NET 1.1 and VS 2005/.NET 2.0 and run it to see whether it can
still repro the behavior. If possible, it is surely recommended to request
a updated version of that 3rd party assembly (target framework 2.0)

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

It is good to know that it won't duplicate the assemblies. However the speed
issue began with the switch to 2.0. We have been using the assemblies under
1.1 for quite a while.

We are going to try and replace all of the 1.1 assemblies ASAP, but it
should be noted that there is definately a huge performance hit when loading
1.1 assemblies within a 2.0 application.

 

[Steven Cheng[MSFT]]

Thanks for your reply Stefan,

Sure, I can imagine the behavior you encounter and that's why I also ask
you for some code logic of the 3rd party component. I'm also interested in
this problem and if you would you can send me some simplified repro code so
that I can also perform some test on my local environment.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Steven,

I'm not sure exactly what you are asking for regarding the 3rd party logic.
One example of a bottleneck was a method that simply used an enum from a 3rd
party assembly, it didn't even call code. The seudo-code is:

ThirdParty.Enum oEnum = (ThirdParty.Enum)Enum.Parse(ThirdParty.Enum,
DataReader["MyEnum"], true);

That was the extent of the usage of the component in the method, but it took
5 seconds to prepare the method before it would execute. After I removed
this line of code the 5 second delay was gone.

Thanks,
Stefan

 

[Steven Cheng[MSFT]]

Thanks for your followup Stefan,

So the problem behavior also occur for very simple code snippet that
referencing a 1.1 assembly in 2.0 application. I think the delay should
only occur at startup time(dynamic compilation) when request the certain
page at the first time, correct?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.