speed issues

[Muddy]

I ran a very simple test. I built a VB.NET app that looped 50,000,000 times changing the value of myClass.element each time. It took 20 sec in the IDE and 20 sec compiled.

I ran the same test using VB6 which ran in 29 sec (IDE) and 25 sec (compiled).

Then in VB6 I changed the class to a UDT (myUDT.element) and it ran in 5 sec (IDE) and 1 sec (compiled).

Does this surprise anyone? It did me, because I thought classes were supposed to be tons more efficient in VB.NET

Also why was there no difference between the IDE and compiled runtimes for the VB.NET test?

Is there such a thing as UDTs in VB.NET? How do you implement them?

[Edneeis]

UDTs in .NET are called Structures. There is no difference from the IDE because even when you run it from the IDE it gets compiled. .NET code is always compiled to the Framework lingo that is why you can't change things on the fly from debugging in the IDE. Also some of the efficiency of classes is not in direct speed. They are more OOP and will save development time through those standards.

How often does your app need to do 50,000,000 changes in a loop anyway? ANd if it did then that would be a call for multithreading.

[DevGrp]

And also remember that classes are reference types, while structs (UDT) are value types. Value types are faster than reference types.

[Muddy]

Originally posted by Edneeis
UDTs in .NET are called Structures. There is no difference from the IDE because even when you run it from the IDE it gets compiled. .NET code is always compiled to the Framework lingo that is why you can't change things on the fly from debugging in the IDE. Also some of the efficiency of classes is not in direct speed. They are more OOP and will save development time through those standards.

How often does your app need to do 50,000,000 changes in a loop anyway? ANd if it did then that would be a call for multithreading.

Thanks for the reply! I currently use UDTs in the VB6 version of my app. It is a loop/calculation intensive program. Overnight runtimes are not uncommon. As it stands, if I migrate to VB.NET and classes, then runtimes of 20 days would not be uncommon (I extrapolate this assumption from my simple test). Of course, this is unacceptable and I cannot afford to migrate if this is the penalty.

Is there anyway I can get comparable runtimes by multithreading? Wouldnt multithreading generate benefit on only the newer P4 processors?

Thanks again for all the info!

[DevGrp]

You can still use structures. Classes are not recommended if you can get better performance from structures. Structures are very similar to classes, except that they are allocated on the stack and store the actual data.

[Muddy]

Originally posted by DevGrp
You can still use structures. Classes are not recommended if you can get better performance from structures. Structures are very similar to classes, except that they are allocated on the stack and store the actual data.

I just ran the test using a structure and it was just as slow as a class ... bummmer

Looks like my only hope is to figure out multithreading. Even then, I could multithread my VB6 app (using the timer trick) and apparently get tons better performance compared to dot net.

bummer!

[hellswraith]

You might want to try switching to Release instead of Debug when you compile. It gets rid of all the Debug stuff and is supposed to increase the run speed. I haven't tried it myself though.


Also, post the test code you created. Maybe we can help you improve it.

[Muddy]

Thanks Hellswraith.

I found the source of the efficiency issue. It seems to be associated with the Decimal data type. I was testing using this to avoid the annoying little problems you have with rounding with doubles (because of the binary storage).

Anyway, I figured it was unfair to compare decimal operations in VB.NET to Double operations in VB6, so I changed the test to this:

VB6 using UDT

Private Sub Command1_Click()
 
        Dim Rover As CDog
        Dim date1 As Date, date2 As Date
        Dim i As Long
        date1 = Now
        For i = 1 To 50000000
            Rover.strVar = "Rover"
            Rover.lngVar = i
            Rover.dblVar = i / 10000000
        Next i
        date2 = Now
        MsgBox (DateDiff("s", date1, date2))
End Sub

VB.NET using Class

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim Rover As New Cdog()
        Dim i As Long
        Dim date1, date2 As Date
        date1 = Now
        For i = 1 To 50000000
            Rover.dblVar = i / 10000
            Rover.strVar = "Rover"
            Rover.lngVar = i
        Next
        date2 = Now
        MessageBox.Show(DateDiff(DateInterval.Second, date1, date2))
    End Sub

and guess what ... VB.NET is about twice as fast. I know this is a highly unscientific test, but I think it gives a rough idea of what to expect before I go off and start migrating.

One other thing I noticed ... anytime a type conversion is needed (ie myInteger = 75/2) VB6 seems to handle it a lot more efficiently. This sort of operation seems to really bog down VB.NET (compared to VB6)

Anyway, looks like I may be able to migrate after all ...

[Edneeis]

Also multithreading should give better performance regardless of cpu just as a side note.

[Muddy]

Originally posted by Edneeis
Also multithreading should give better performance regardless of cpu just as a side note.

Thanks for that. Ill try to educate myself on threading. There is a lot in the help, but hasnt been very good reading so far.