• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Any experience converting VB6 to VB.NET? how did it go?

N

NTB

Diamond Member
what sort of changes, in terms of speed, did you see after the conversion? I'm working with another person at my office on something like this, and while we have a working .NET program, the execution time has more than doubled. A little background information:

The original VB6 application is basically a giant excel Macro. it uses excel to open and format a pipe-delimited text file, then save that formatted 'report' as a regular excel (*.xls) file. There's a whole list of files to go through and perform these operations on, and the original VB6 code could accomplish this in roughly 2.5 to 3 hours. The .NET version, meanwhile, takes close to 7 hours to chew through exactly the same list.

Unfortunately, I have no code to post; I was just wondering if anyone else had experienced anything like this and, if so, if you have ever found a way to speed things up. I'm not terribly familiar with .NET myself, so at this point I'm stumped. Any suggestions would be appreciated!

Thanks,

Nathan
 
.NET is much faster but it takes some time to start up when you launch the program for the first time. However you can make use of multi-threading to speed up things.
 
Originally posted by: Aberforth
.NET is much faster but it takes some time to start up when you launch the program for the first time. However you can make use of multi-threading to speed up things.
Click to expand...

That's what we were told, but our current experience is showing us otherwise, and we're trying to figure out why. If I copy both versions to my own workstation (2-year-old P4, 1GB RAM, Windows XP) and run them, the VB.NET version *is* faster. The test box is another matter: 4 CPUs, Windows 2000 server, 4GB RAM. The production box uses the same OS, but I believe it has a few more processors. On test server, VB.NET slows to a crawl.

Nathan
 
.NET handles only one function/method at a time by default, you can test this if you want for example: let's say you have a single threaded disc scanning app, during the scanning process you notice the progress bar is not being updated until you finish that operation this is because .net runtimes push everything into a single pipeline by default but unlike VB6 .net is has new features that allows better optimization. Your code isn't optimized for multiple CPUs, you have to write a custom code to create separate threads to handle multiple tasks. For 4 CPU's - you have to have to create 4 individual threads- there isn't a limit but depends on the program complexity.
 
Originally posted by: Aberforth
.NET handles only one function/method at a time by default, you can test this if you want for example: let's say you have a single threaded disc scanning app, during the scanning process you notice the progress bar is not being updated until you finish that operation this is because .net runtimes push everything into a single pipeline by default but unlike VB6 .net is has new features that allows better optimization. Your code isn't optimized for multiple CPUs, you have to write a custom code to create separate threads to handle multiple tasks. For 4 CPU's - you have to have to create 4 individual threads- there isn't a limit but depends on the program complexity.
Click to expand...

Isn't VB6 the same way - i.e., by default it can only do one thing at a time?
 
Originally posted by: Dhaval00
What kind of application is it? Website, Windows Service, Web Service, Windows Forms, Remoting? What exactly is the application's purpose?
Click to expand...

The purpose (as stated in the original post 😉 ) is to take a pipe-delimited data file created by another process and turn it into a formatted Excel spreadsheet. There are also a couple calculations done in addition to the formatting, and there are multiple reports to be created, which is why it takes so long.
 
Originally posted by: NTB
Originally posted by: Aberforth
.NET handles only one function/method at a time by default, you can test this if you want for example: let's say you have a single threaded disc scanning app, during the scanning process you notice the progress bar is not being updated until you finish that operation this is because .net runtimes push everything into a single pipeline by default but unlike VB6 .net is has new features that allows better optimization. Your code isn't optimized for multiple CPUs, you have to write a custom code to create separate threads to handle multiple tasks. For 4 CPU's - you have to have to create 4 individual threads- there isn't a limit but depends on the program complexity.
Click to expand...

Isn't VB6 the same way - i.e., by default it can only do one thing at a time?
Click to expand...

VB 6 uses machine code that is directly handled by the processor but you have to use external API's to handle multi-threading which is very difficult and unreliable but .NET Exe is a byte code based on MS Intermediate Language (MSIL) and managed by .NET framework. MSIL allows effortless integration of new technologies with a very little code without raw access to direct system internals.
 
Originally posted by: NTB
Originally posted by: Dhaval00
What kind of application is it? Website, Windows Service, Web Service, Windows Forms, Remoting? What exactly is the application's purpose?
Click to expand...

The purpose (as stated in the original post 😉 ) is to take a pipe-delimited data file created by another process and turn it into a formatted Excel spreadsheet. There are also a couple calculations done in addition to the formatting, and there are multiple reports to be created, which is why it takes so long.
Click to expand...

Sorry... wasn't awake. 😉

What connection type are you using to handle the Excel files from within .NET?

I think the bottleneck in your case may be the underlying connection object's performance, not .NET. MSIL is super-fast compared to VB6. But then Excel macros were made for VB6 which has native support for querying Excel.

Have you put timers around your connection/command objects to see which operation is taking the longest time?

Edit: I know you mentioned you can't post any code, but I think people may be able to shed more light on the subject if you can post some code.
 
With VB.Net there are "many ways to skin a cat". Your choice or the conversion tools choice of functions can greatly affect performance. Take a look at http://vbnotebookfor.net/2007/...sion-methods-in-vbnet/ and you will see what I mean. In this article the author attempts several different ways of converting a string to a number and finds differing performance between these functions. This performance difference will also exist between VB.net and VB 6. A fast performing function in VB.net way be slow in VB 6 and vice-versa.

The key is to use a profiler to determine which calls are slowing performance and to rewrite them using better performing functions. With enough effort you should be able to get the two to perform about equally. This brings up the question though, that if the VB 6 app is working why replace it?
 
The conversion of VB6 to .NET code by any means other than a complete and total rewrite is usually a recipe for disaster. I have tried converting multiple projects with very limited success. As KB pointed out, the converter may not always choose the best functions and procedures. The built-in converter that comes with Visual Studio is crap.

techfuzz
 
I'm working on a VB6 --> VB9 conversion. Most of the coding is for late-binding excel to read and write from/to a SQL 2000 database. The biggest pain was converting the old code from ByRef to ByVal. I would never suggest someone rely on the wizard to do this.
 
Originally posted by: brandonbull
I'm working on a VB6 --> VB9 conversion. Most of the coding is for late-binding excel to read and write from/to a SQL 2000 database. The biggest pain was converting the old code from ByRef to ByVal. I would never suggest someone rely on the wizard to do this.
Click to expand...
Grab a powerful text editor like UltraEdit and it'll make quick work of all those mind-numbing code replacements you have to do. I recently had to go through ~250 files to remove and replace blocks of code. It took about 5 minutes 🙂

techfuzz
 
I am converting a decent-sized app from VB6 to VB.NET at the moment. I am not using the conversion wizard but instead rewriting it from scratch. It's working about twice as fast for the data importing I do. (I import data from files, tabulate it, and display it in ListViews.) More importantly, .NET is infinitely more convenient because it has all the methods I need and I don't need to use third-party libraries, especially for the GUI.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top