Why VB 6.0??

Well i did a initial version of this code...

Code:

---

    Private Sub DrawStuff()
        Dim Rct As Rectangle, W As Integer, H As Integer
        Dim I As Integer, J As Integer, X1 As Integer, Y1 As Integer
        Dim X2 As Integer, Y2 As Integer
        Dim BmapBuffer As Image
        Dim BufferGObj As Graphics

        Dim T As Integer

        T = GetTickCount

        Rct.Size = Me.ClientSize

        W = Rct.Width
        H = Rct.Height

        BmapBuffer = New Bitmap(W, H)
        BufferGObj = Graphics.FromImage(BmapBuffer)

        X2 = 30
        Y2 = 40

        BufferGObj.Clear(Color.FromArgb(&H60, &H60, &H60))

        J = CInt(TextBox1.Text)
        For X1 = 0 To W Step X2
            For Y1 = 0 To H Step X2
                For I = 1 To J
                    Dim c As New Pen(Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256))
                    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)
                Next
            Next
        Next
        Me.Text = GetTickCount - T

        Me.BackgroundImage = New Bitmap(BmapBuffer)

    End Sub

---

This round the time difference is closer, however vb6 still won..
I'll se what i can do to squeese some more performance out of .NET ( Remember i've only been working on .NET for about a year now..)
see attached image..

VB6 left , VB.Net right..

That's very interesting Gremmy! And thanks for doing these tests.

Wouldn't API help .net just as it does VB6? Or are you purposely not using API?

This could be run in a thread, and draw each independent of the others.

Code:

---

              For I = 1 To J
                    Dim c As New Pen(Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256))
                    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)
                Next

---

with DrawLine(J) as a new thread. For imagination, they could alternate directions. I'll try to dig up the code sample that we worked on here a while back.

I saw a 400x improvement running 26x26 in separate threads doing web requests.

Quote:

---

Originally Posted by wizbang

That's very interesting Gremmy! And thanks for doing these tests.

Wouldn't API help .net just as it does VB6? Or are you purposely not using API?

---

Like I stated. People in the .net shouldn't go outside the "box". If they had to, they are missing the point in the .net.

For games running slow because they were built out out of the c++ is wrong. Everyone knows that games run slow if you have a slow video card and not the cpu typically.

I like the answers about jumping out of the plane ;)

Managed to shave a few ms by moving the DIM outside of the loop, and fixing the pen.color slightly for another 50ms.

Code:

---


Public Class Form1

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        TextBox1.Text = 100
        DrawStuff()
    End Sub

    Private Sub DrawStuff()
        Dim Rct As Rectangle, W As Integer, H As Integer
        Dim I As Integer, J As Integer, X1 As Integer, Y1 As Integer
        Dim X2 As Integer, Y2 As Integer
        Dim BmapBuffer As Image
        Dim BufferGObj As Graphics

        Dim T As Integer

        T = Environment.TickCount

        Rct.Size = Me.ClientSize

        W = Rct.Width
        H = Rct.Height

        BmapBuffer = New Bitmap(W, H)
        BufferGObj = Graphics.FromImage(BmapBuffer)

        X2 = 30
        Y2 = 40

        Dim formGraphics As System.Drawing.Graphics
        formGraphics = Me.CreateGraphics()

        J = CInt(TextBox1.Text)
        Dim c As New Pen(Color.Black)
        For X1 = 0 To W Step X2
            For Y1 = 0 To H Step X2
                For I = 1 To J
                    c.Color = Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256)
                    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)
                Next

            Next
        Next
        Me.Text = Environment.TickCount - T
        Me.BackgroundImage = New Bitmap(BmapBuffer)
    End Sub

End Class

---

Doesn't dot net also have the ability to take advantage of the multi core processors? Would be interesting to see how much faster it goes when offloading some of the work to a second core or 3rd and 4th.

http://msdn.microsoft.com/en-us/magazine/cc163340.aspx

Quote:

---

Originally Posted by WizBang

That's very interesting Gremmy! And thanks for doing these tests.

Wouldn't API help .net just as it does VB6? Or are you purposely not using API?

---

Yes.. I'm pupoisely avoiding using API's as .NET has the Graphics Object that is suposed to be the API Equivelent..

The more I'm using it the more I'm thinking that it may be a wraper class for the API's, and you will get a little lag from the wrappers...

Gremmy..

Quote:

---

Originally Posted by GremlinSA

Yes.. I'm pupoisely avoiding using API's as .NET has the Graphics Object that is suposed to be the API Equivelent..

The more I'm using it the more I'm thinking that it may be a wraper class for the API's, and you will get a little lag from the wrappers...

Gremmy..

---

You are correct. One big issue with you implementation was that you are creating the Pen inside a loop. Pen implements IDisposable, and you were not calling Dispose.

This means that each time through the loop, the PEN (effectively) has to get added to the finalizer queue, which introduces serious processing overhead.

While I have not tested it. I would expect adding a Dispose() call would give you nearly the identical performace dglienna gets by moving the Pen call out of the loop.

When you use any object that implmenents IDisposable, you MUST insure that Dispose() is called on a reliable basis. One quick way to check, is to use PerfMOn to watch how many finalizers are ocuring. Unless there are exceptions occuring (which should also be minimized) this count should remain at 0 for the entire life of the program.

Run PermFom and look at the GC counters both with and without the Dispose(). You will see a drastic difference.

Quote:

---

Originally Posted by dglienna

This could be run in a thread, and draw each independent of the others.

---

The redundant loop is being used to exaggerate the total time that the function takes to execute, in order to get meaningful numbers for the comparison. Using separate threads would mess that up.

So in the interest of exploring this, I've modified the function to eliminate the need for a redundant loop. What I did is to use the value entered into the TextBox to determine the size of the rectangles. Obviously, it takes a much smaller rectangle to slow the whole thing down enough, but I think it works good enough to get numbers we can use.

I have just been running Gremmys code.

Because I have a "poor" video environment (I told you I do not generally do graphics :D ), I am seeing numbers about 8x what others are reporting, regardless of environment. However I am seeing the same RATIONS (approx). As a result, I will NOT post numbers, just observations.

1) As I indicated in a previous reply, NOT Disposing the Pen that is created inside the loop is a major ovehead. Adding the Dispose() or moving the Managd Pen creation out of the loop yields statistically equivilant results.

2) Comparing the Pen setup (Pen.Color = ) to the Draw. Indicates that 2.28 time units are used for each change to the pen. 6.16 time units are used for each call to rectangle. So the pen is about 25% of the time the draw about 75% of the tims.

3) Release Builds are Measurable Faster (about 25%) than Release Builds. The differential between DEbug and Release is typically larger with Managed Code than with other environments. It is important that all timing tests be run as Release Builds, and WITHOUT Visual Studio (or any other debugger) active on the System. (Having a debugger loaded in memory - regardless of if you are actually debuging your application MAY have significant impact on program excution).

I am continuing to break down #2. For those interested, I am using the ANTS profiler (www.red-gate.com). There is a 14 day free evaluation available for anyone interested in finding out where time is spend in their managed applications.

The differential in Time on

Code:

---

    c.Color = Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256)
    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)

---

Is spent in parameter validation and result verification before calling the Native GDI. These are both important elements in having a program which behaves in a well defined manner, and is secure (many code native routines can only do limited validation on parameters), but it does come at a price.

I agree that for a graphics intensive application that this can present a problem. Regardless of language optimizing your drawing to minimize the number of discrete calls will result in a performance improvement, but this is especially true for managed code.

If the goal was to have identical functionallity for the above two lines, then the VB6.0 code needs to check all parameters for validity and also check the return status of all API calls.

Quote:

---

Originally Posted by TheCPUWizard

The differential in Time on

Code:

---

    c.Color = Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256)
    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)

---

Is spent in parameter validation and result verification before calling the Native GDI. These are both important elements in having a program which behaves in a well defined manner, and is secure (many code native routines can only do limited validation on parameters), but it does come at a price.

I agree that for a graphics intensive application that this can present a problem. Regardless of language optimizing your drawing to minimize the number of discrete calls will result in a performance improvement, but this is especially true for managed code.

If the goal was to have identical functionallity for the above two lines, then the VB6.0 code needs to check all parameters for validity and also check the return status of all API calls.

---

What this acknowledges, is that part of the difference we see in performance is due to the fact that the .net code is managed. Should we purposely cripple the VB6 code just to compensate for an intrinsic difference in the languages? It's part of how the two differ, just as VB6 doesn't have a DrawRectangle function.

However, since the VB6 code is using the RGB() function, there IS some checking being done on that anyway. That's just part of the language too.

Quote:

---

Originally Posted by WizBang

What this acknowledges, is that part of the difference we see in performance is due to the fact that the .net code is managed. Should we purposely cripple the VB6 code just to compensate for an intrinsic difference in the languages? It's part of how the two differ, just as VB6 doesn't have a DrawRectangle function.

---

It has nothing to do with the "managed" aspect. I have been trying to measure that aspect specifically (the pinning of the objects and the marshelling), but it is so small a part of the difference (hand calculating it by looking at the executed code indicates it accounts for less than 1% of the difference).

It has everything to do with writing ROBUST code. Consider (completely language/platform independant if you are going to write a sub-routine that will call the following (hypothetical) function:

Quote:

---

Method: int DoSomeThing(int param)

DoSomething will return a poisitive "calculated value" based on the passed parameter and "some external condition".

The behaviour is defined for 100<param<1000. Values outside this range result in undefinded behaviour.

If the "external condition" is in an invalid state, the result will be -1.

---

Writing code that does not check the parameter and the return value, has inherent risks. Accidently passing 1002 as a parameter could return meaningless results, cause and exception to be thrown, cause your computer to crash, ......

This would simply be iresponsible. Again, this is independant of any specific techniology.

By calling API's directly (again from any environment) it becomes the developers responsibility to manually code the correct "safe" behavior.

By using the .NET framework, the checks are automatically in place, and the developer CAN NOT be ir-responsible.

For the two lines in question:

Code:

---

Public Shared Function FromArgb(ByVal red As Integer, ByVal green As Integer, ByVal blue As Integer) As Color
    Return Color.FromArgb(&HFF, red, green, blue)
End Function

 Public Shared Function FromArgb(ByVal alpha As Integer, ByVal red As Integer, ByVal green As Integer, ByVal blue As Integer) As Color
    Color.CheckByte(alpha, "alpha")
    Color.CheckByte(red, "red")
    Color.CheckByte(green, "green")
    Color.CheckByte(blue, "blue")
    Return New Color(Color.MakeArgb(CByte(alpha), CByte(red), CByte(green), CByte(blue)), Color.StateARGBValueValid, Nothing, DirectCast(0, KnownColor))
End Function

 Private Sub New(ByVal value As Long, ByVal state As Short, ByVal name As String, ByVal knownColor As KnownColor)
    Me.value = value
    Me.state = state
    Me.name = name
    Me.knownColor = CShort(knownColor)
End Sub

 Public Sub DrawRectangle(ByVal pen As Pen, ByVal x As Integer, ByVal y As Integer, ByVal width As Integer, ByVal height As Integer)
    If (pen Is Nothing) Then
        Throw New ArgumentNullException("pen")
    End If
    Dim status As Integer = Gdip.GdipDrawRectangleI(New HandleRef(Me, Me.NativeGraphics), New HandleRef(pen, pen.NativePen), x, y, width, height)
    Me.CheckErrorStatus(status)
End Sub

 DllImport("gdiplus.dll", CharSet:=CharSet.Unicode, SetLastError:=True, ExactSpelling:=True)> _
Friend Shared Function GdipDrawRectangleI(ByVal graphics As HandleRef, ByVal pen As HandleRef, ByVal x As Integer, ByVal y As Integer, ByVal width As Integer, ByVal height As Integer) As Integer
End Function

Private Sub CheckErrorStatus(ByVal status As Integer)
    If (status <> 0) Then
        If ((status = 1) OrElse (status = 7)) Then
            Dim num As Integer = Marshal.GetLastWin32Error
            If (((num = 5) OrElse (num = &H7F)) OrElse (((UnsafeNativeMethods.GetSystemMetrics(&H1000) And 1) <> 0) AndAlso (num = 0))) Then
                Return
            End If
        End If
        Throw Gdip.StatusException(status)
    End If
End Sub

---

The two bold statements are the ONLY aspect that is induced because the code is "managed".

If you plug these methods (with adjustments) into your VB6.0 implementation, then you will have programs with equivilant levels of reliability.

This would then be a fair comparision (ie meeting the same requirements using two different languages).

Woot !!!!!

Now we got something that working !!!!!!

Code:

---

  Private Sub DrawStuff()
        Dim Rct As Rectangle, W As Integer, H As Integer
        Dim I As Integer, J As Integer, X1 As Integer, Y1 As Integer
        Dim X2 As Integer, Y2 As Integer
        Dim BmapBuffer As Image
        Dim BufferGObj As Graphics
        Dim T As Integer
        T = GetTickCount
        Rct.Size = Me.ClientSize
        W = Rct.Width
        H = Rct.Height
        BmapBuffer = New Bitmap(W, H)
        BufferGObj = Graphics.FromImage(BmapBuffer)
        BufferGObj.Clear(Color.FromArgb(&H60, &H60, &H60))
        Dim c As New Pen(Color.White)
        J = CInt(TextBox1.Text)
        If J < 1 Then J = 1
        X2 = J
        Y2 = J * 1.4
        For X1 = 0 To W Step X2
            For Y1 = 0 To H Step X2
                'For I = 0 To J
                c.Color = Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256)
                BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)
                'Next
            Next
        Next
        Me.Text = GetTickCount - T
        Me.BackgroundImage = New Bitmap(BmapBuffer)
    End Sub

---

CG has a 100k limit on image files, so the image was clipped, however i can promise that they are the same size... (Full size viewable here)

Again VB6 left, .NET right..

Quote:

---

Originally Posted by TheCPUWizard

I have just been running Gremmys code.

Because I have a "poor" video environment (I told you I do not generally do graphics :D ), I am seeing numbers about 8x what others are reporting, regardless of environment. However I am seeing the same RATIONS (approx). As a result, I will NOT post numbers, just observations.

---

Not a problem, we do need some one to interpret the number's, and give sound observations..

Quote:

---

Originally Posted by TheCPUWizard

3) Release Builds are Measurable Faster (about 25%) than Release Builds. The differential between DEbug and Release is typically larger with Managed Code than with other environments. It is important that all timing tests be run as Release Builds, and WITHOUT Visual Studio (or any other debugger) active on the System. (Having a debugger loaded in memory - regardless of if you are actually debuging your application MAY have significant impact on program excution).

---

In VB6 i have seen this same differential, and 25% is about the same i've noticed..
However in VB.NET the number is a lot smaller, If any, in working on these examples running the build and running in Debug has yeilded identical numbers..