Converting from classic ASP/vb6 to dotnet

[josverhoeff]

My vb6 to vb.net converted application performs about twice as slow as the classic ASP version.

Here is the setup: I have an old ASP application that uses for most of its function calls a vb6 dll of 30000 + lines of code.

I managed to convert the dll into a vb.net dll, built in caching for dataset retrieval, got rid of all interop calls (no more ODBC, but using datasets).

The application is a Content Management system, an oldie, but very complete

Still, the application, running the same web site on the same server, is twice as slow (6 seconds load time insead of 3) as the original in classic ASP.
I swithed off all debug options (in web.config) and run the release compiled version. IIS caching is on

I have the impression that the actual calls to the vb.net dll are what is slow. Are there ways to speed that up ?

[Begginnerdev]

If you are using datasets - You may have the problem of opening and closing a connection the same table multiple times.

When I do this I declare one connection that will stay open until all operations are completed on that table - then close.

If this is not the case - one thing that you can do is to create a test in the dll solution to check the code in debug to see if it is doing something undesirable.

[TnTinMN]

First off, .Net will be slower than a natively compiled VB6 app.

One thing to check for is late binding of objects. This will really slow things down. If you have not already done so, add the following to the top of your code and then the fun begins; work through all of the IDE error and warning messages.

Option Strict On

not necessary but I also recommend:
Option Explicit On - Inferred by using Option Strict
Option Infer Off

References:

Early and Late Binding

Option Explicit and Option Strict in Visual Basic .NET and in Visual Basic

[josverhoeff]

Just to keep you informed, I am working on the strong typing of all function parameters and variables to early bind them. Hopefully it will speed things up, but for 30 KLOC, nothing strong typed, this will take a while.

[josverhoeff]

Ok, I'll mark his as solved :

After doing (I thought) about 90% of the strong typing work, I reset the "strict on" option to "off", recompiled in release mode and did another test. To my huge disappointment things were not faster at all. I swallowed my disappointment and did the other 10%, since I did believe that early binding should help.

Yesterday I was able to compile with no errors ( I do still have tons of warnings ) with strict on and infer off, and the speed was up to par with the speed of the classic ASP version

I had to switch off some methods enumerating IIS sites (still have to find the vb.net types of iisObject)

But found one other factor slowing things down: I used the windows scripting host to enumerate files and to check their presence. Changing that to the system.io equivalents made the application about 50% faster tham the original.

Thanx a bunch

[TnTinMN]

Thanks for the update. Good to know that it is paying off.

If you can not find or create a suitable interface for the iisObject, move that code to its own class or module in a separate file and set the options for that file as needed.

I've seen people use WSH before for that and could never figure out their logic for doing so when the language supports equivalent functionality. Marshalling values across the interop boundary is time consuming and in this case just a waste of time.