VS 2015 [RESOLVED] VB.net (vs 2013) - Performance issue with arrays-VBForums
Results 1 to 7 of 7

Thread: [RESOLVED] VB.net (vs 2013) - Performance issue with arrays

  1. #1

    Thread Starter
    New Member
    Join Date
    May 2012
    Posts
    6

    Resolved [RESOLVED] VB.net (vs 2013) - Performance issue with arrays

    I have been having performance issues, and have isolated the root of the issue. I am using arrays in quite a few places, and after stripping the program down to just a menu that opens a form with the code below, I found this array declaration is what is slowing the program down. Here is my code:

    Code:
    Public Class RUNFORM
        Private v_saved_yn As String
        Private count_seq As Integer
        Private ItemCnt As Integer
        Private ActivateFormVal As Integer
        Private lastbox As TextBox
        Private Class CountList
            Private Property COUNTARRAYID As Integer
            Private Property ORDERLINESEQ As String
            Private Property ITEMID As String
            Private Property ITEMDES As String
            Private Property COUNTA As String
            Private Property UMIDA As String
            Private Property COUNTOH As String
            Private Property COUNTVAR As String
        End Class
    
        Private CountRec(9999, 9999) As String
        Private tbox(99, 99) As TextBox
    
        Private mintRowStart As Integer
    
        Private Sub CANCELBTN_Click(sender As Object, e As EventArgs) Handles CANCELBTN.Click
            MENU.Show()
            Me.Close()
    
        End Sub
    
    End Class
    I can go from the menu to this form about 3 to 5 times without issues. Then, it start locking up when I try to open this form. After it starts locking up, everything starts locking up. If I remove the Countlist, CountRec, and tbox, and rerun it, I can go from the menu to this form an infinite number of times without issue, so I know this is the source of the problem.

    Is there a way to completely remove these arrays from memory as I close the form? Or, should I initialize the arrays to a null value in some way on the form startup? I use arrays in similar manners all throughout the program, so they are essential.

    Please advise, and thanks in advance.

  2. #2
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,462

    Re: VB.net (vs 2013) - Performance issue with arrays

    The problem is most likely the TextBox array, but that String array isn't helping, either.

    The String array has to allocate space for 99,980,001 objects. On an x86 machine, that's 381 MB of space when empty, larger when populated. Ouch.

    The TextBox array is more modest at 9,801 items (38 KB), but introduces another problem. Presumably you put TextBoxes in it. Each TextBox represents a GDI window handle, and you're only allowed to have about 65,000 of those total per process. Since you (presumably) create those TextBoxes yourself, the Form doesn't automatically clean them up. So it makes sense that somewhere around the 5th or 6th time you create nearly 10,000 TextBoxes, everything goes bad.

    If you are indeed creating that many TextBoxes, it is imperative that when the form closes, you call Dispose() on each and every one of them. That window handle they hold represents memory the .NET garbage collector can't collect. So if you don't call Dispose(), that memory stays used.

    In theory, the GC should try to collect the old forms. In theory, that should call a finalizer on the TextBoxes. In practice, there are a lot of reasons it might not. For one, it doesn't understand that the TextBoxes represent unmanaged memory, so it may not see them as a big deal and won't run before they become a problem. You've still got that issue of nearly 400MB of empty String array to deal with. That's a huge allocation. My guess is via some mechanism, your forms remain rooted in the GC so it can't collect them.

    This form itself is pretty insightful, but I'd have to see more code to understand. Mostly I am suspicious of that TextBox array, that is a ridiculous number of controls to create. Most Forms start misbehaving at somewhere around 100 controls.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  3. #3
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,579

    Re: VB.net (vs 2013) - Performance issue with arrays

    That's not just a ridiculous number of textboxes, it's also a useless number. A textbox is a User Interface element, but no human is going to meaningfully view or interact with nearly 10,000 controls on a single form. No matter what you are doing, you can do that with FAR fewer controls, because there is a limit to what can meaningfully be displayed on a screen. That limit is likely around 100 textboxes, and even that would be a rare case. Above that, a DataGridView makes more sense.
    My usual boring signature: Nothing

  4. #4

    Thread Starter
    New Member
    Join Date
    May 2012
    Posts
    6

    Re: VB.net (vs 2013) - Performance issue with arrays

    Okay I am not using that many textboxes in my program, just did it that way for my test form because I use a very small textbox array in one of my forms in my real program.

    In the code I listed in the question above, I made a simple form just to isolate the issue. No realtime use.

    However, I do use the large CountRec array in a different form, because I am gathering a bunch of data from a user's comma delimited file, and error checking the data. So I do need a large array to separate and check each piece of data.

    Mr. Sitten Spynne,

    I tried to use Me.dispose() instead of Me.close() per your suggestion, but my form still starts to lock up.

  5. #5
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,579

    Re: VB.net (vs 2013) - Performance issue with arrays

    Me.dispose isn't what Sitten suggested. He suggested iterating through each textbox and disposing each of them, probably in the Dispose method of the form.

    In the actual project, if you are not using that many controls, is the behavior still EXACTLY the same? How many controls do you have in that smaller case?

    You still don't need that monster array. At some point, you have to divide a problem into chunks rather than reading in the whole thing in one shot. If the problem is due to the size of that array, as it may be, then you've reached the point where you need to start chunking some stuff up. However, the fact that you can open the form a few times before any problem starts happening certainly makes it sound like some large chunk of memory is not being released, and that array is the largest block of memory. Specifically setting it to Nothing before the form closes may help, as it should make it clear that it can freely be recovered, but that brings up a different point: What do you mean by "locking up". If the app simply stops working, and never moves, that is quite a bit different from it getting really slow, or freezing for a few seconds, then moving forwards. So, what is your definition of locking up?
    My usual boring signature: Nothing

  6. #6

    Thread Starter
    New Member
    Join Date
    May 2012
    Posts
    6

    Re: VB.net (vs 2013) - Performance issue with arrays

    Wow I set the arrays to Nothing at form close, and it prevented the locking up. THANKS! FYI by locking up, I mean I press the button to go to the next form and it does nothing for a few minutes.

  7. #7
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,579

    Re: [RESOLVED] VB.net (vs 2013) - Performance issue with arrays

    If that solution fixed it, then the problem was something Sitten mentioned. The form is staying rooted in the GC, or at least the array was, but it amounts to the same thing: Because that array is so massive, the GC is certain to be called fairly often, because you are gobbling up memory like crazy. However, because the array still had some variable holding its reference (the array variable, and the form held that), the GC couldn't figure out that the array was safe to destroy. Normally, this isn't an issue, but with a memory object as big as that array, it became a real issue as memory management became a challenge for the OS itself.

    That isn't the common definition of locking up, cause normally when a program locks up....it doesn't come back. That is usually due to something utterly silly, sometimes due to something difficult to figure out, and not due to memory management. What you describe is the program becoming exceedingly sluggish to the point that it acts like it is locked. After all, if an app does nothing for a few minutes, most people assume the worst and close it. What was probably happening was some serious hard drive thrashing. It used to be that you could hear or see when the drives were in use. That's cause they sucked. These days, mechanical hard drives are super quiet, while solid state drives make no noise of any sort. Still, the OS has a certain amount of RAM, and a chunk of the drive for a swap file. As long as you stay in RAM, all is pretty fast. Once you start swapping multi megabytes, or even gigabytes to and from the swap file, you can expect the performance to degrade severely. That's likely what you were seeing.
    My usual boring signature: Nothing

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width