Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C#
  4. DataGridView, Memory Usage

DataGridView, Memory Usage

Scheduled Pinned Locked Moved C#
questioncssperformancelearning
7 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    Jitse
    wrote on last edited by
    #1

    Good day I've been experimenting a bit with the DataGridView, and its memory usage. If you add a high amount of rows to the grid, and then clear it, it apparently won't clear its memory as well. It's as if the rows are still in the memory, but dereferenced. When you populate the grid again, with alot of data, the memory usage keeps on going up, as if he now has two lists of rows. This goes on for a while every time I clear and populate again, until the memory usage gets to a certain amount, then the application freezes for a very short while (some milliseconds) and the memory usage gets reduced back to the normal level of one populated DataGridView. This is just the GC doing its work, but I didn't know he did it that sporadicly. He also doesn't seem to work in function of time, but in function of total memory usage. He watches how high the memory usage goes, and when it gets to a certain level he finally starts working. The method GC.Collect() solves this all of course. So now my question is, when you're working with DataGridViews and a high amount of data, is it recommended to actually just always do a GC.Collect after you cleared the grid? Thanks in advance.

    C 1 Reply Last reply
    0
    • J Jitse

      Good day I've been experimenting a bit with the DataGridView, and its memory usage. If you add a high amount of rows to the grid, and then clear it, it apparently won't clear its memory as well. It's as if the rows are still in the memory, but dereferenced. When you populate the grid again, with alot of data, the memory usage keeps on going up, as if he now has two lists of rows. This goes on for a while every time I clear and populate again, until the memory usage gets to a certain amount, then the application freezes for a very short while (some milliseconds) and the memory usage gets reduced back to the normal level of one populated DataGridView. This is just the GC doing its work, but I didn't know he did it that sporadicly. He also doesn't seem to work in function of time, but in function of total memory usage. He watches how high the memory usage goes, and when it gets to a certain level he finally starts working. The method GC.Collect() solves this all of course. So now my question is, when you're working with DataGridViews and a high amount of data, is it recommended to actually just always do a GC.Collect after you cleared the grid? Thanks in advance.

      C Offline
      C Offline
      Colin Angus Mackay
      wrote on last edited by
      #2

      Jitse wrote:

      This is just the GC doing its work, but I didn't know he did it that sporadicly. He also doesn't seem to work in function of time, but in function of total memory usage. He watches how high the memory usage goes, and when it gets to a certain level he finally starts working

      It is a function of memory usage.

      Jitse wrote:

      The method GC.Collect() solves this all of course. So now my question is, when you're working with DataGridViews and a high amount of data, is it recommended to actually just always do a GC.Collect after you cleared the grid?

      Generally GC.Collect() shouldn't be used. You should allow the garbage collector to figure out the optimisation. I would guess that the slowness is due to a high number of very small objects being cleared up.

      Upcoming FREE developer events: * Developer Day Scotland Recent blog posts: * Different ways to add point data in SQL Server 2008 * Spatial References in SQL Server 2008 My website |

      J 1 Reply Last reply
      0
      • C Colin Angus Mackay

        Jitse wrote:

        This is just the GC doing its work, but I didn't know he did it that sporadicly. He also doesn't seem to work in function of time, but in function of total memory usage. He watches how high the memory usage goes, and when it gets to a certain level he finally starts working

        It is a function of memory usage.

        Jitse wrote:

        The method GC.Collect() solves this all of course. So now my question is, when you're working with DataGridViews and a high amount of data, is it recommended to actually just always do a GC.Collect after you cleared the grid?

        Generally GC.Collect() shouldn't be used. You should allow the garbage collector to figure out the optimisation. I would guess that the slowness is due to a high number of very small objects being cleared up.

        Upcoming FREE developer events: * Developer Day Scotland Recent blog posts: * Different ways to add point data in SQL Server 2008 * Spatial References in SQL Server 2008 My website |

        J Offline
        J Offline
        Jitse
        wrote on last edited by
        #3

        I've got a testing application, that has about 57MB of memory usage with filled DataGridView. Now the GC only starts working at about 200MB. That's quite alot. I'd rather have an application using 57MB all the time, instead of always getting to 200MB before optimization starts to get it back to 57MB.

        J 1 Reply Last reply
        0
        • J Jitse

          I've got a testing application, that has about 57MB of memory usage with filled DataGridView. Now the GC only starts working at about 200MB. That's quite alot. I'd rather have an application using 57MB all the time, instead of always getting to 200MB before optimization starts to get it back to 57MB.

          J Offline
          J Offline
          Judah Gabriel Himango
          wrote on last edited by
          #4

          The .NET 2.0 Service Pack 1 adds some new APIs to help you control this behavior. Look up System.Runtime.GCSettings class.

          Tech, life, family, faith: Give me a visit. I'm currently blogging about: Upon this disciple I'll build my new religion? The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

          J 1 Reply Last reply
          0
          • J Judah Gabriel Himango

            The .NET 2.0 Service Pack 1 adds some new APIs to help you control this behavior. Look up System.Runtime.GCSettings class.

            Tech, life, family, faith: Give me a visit. I'm currently blogging about: Upon this disciple I'll build my new religion? The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

            J Offline
            J Offline
            Jitse
            wrote on last edited by
            #5

            I've got .NET Framework 2 SP1, and I don't see anything interesting in that class. All it has are these two properties: // Gets a value indicating whether server garbage collection is enabled. System.Runtime.GCSettings.IsServerGC // Sets the behavior of the GC System.Runtime.GCSettings.LatencyMode The LatencyMode could be interesting, if it wouldn't only have these three unusable choices: GCLatencyMode.Batch // for non-UI applications GCLatencyMode.Interactive // for UI applications, used by default GCLatencyMode.LowLatency // when you don't want the GC to interrupt time-sensitive operations Nothing interesting there. Edit: On MSDN it says this: Use the Collect method when there is a significant reduction in the amount of memory being used at a defined point in your application's code. For example, if your application uses a complex dialog box that has several controls, calling Collect when the dialog box is closed could improve performance by immediately reclaiming the memory. If they already think a complex dialog box is a good situation to collect garbage after with GC.Collect, I think a DataGridView with a hundred thousand rows that has been cleared is a good reason too. That's just my unexperienced opinion though.

            modified on Tuesday, February 26, 2008 3:36 PM

            J 1 Reply Last reply
            0
            • J Jitse

              I've got .NET Framework 2 SP1, and I don't see anything interesting in that class. All it has are these two properties: // Gets a value indicating whether server garbage collection is enabled. System.Runtime.GCSettings.IsServerGC // Sets the behavior of the GC System.Runtime.GCSettings.LatencyMode The LatencyMode could be interesting, if it wouldn't only have these three unusable choices: GCLatencyMode.Batch // for non-UI applications GCLatencyMode.Interactive // for UI applications, used by default GCLatencyMode.LowLatency // when you don't want the GC to interrupt time-sensitive operations Nothing interesting there. Edit: On MSDN it says this: Use the Collect method when there is a significant reduction in the amount of memory being used at a defined point in your application's code. For example, if your application uses a complex dialog box that has several controls, calling Collect when the dialog box is closed could improve performance by immediately reclaiming the memory. If they already think a complex dialog box is a good situation to collect garbage after with GC.Collect, I think a DataGridView with a hundred thousand rows that has been cleared is a good reason too. That's just my unexperienced opinion though.

              modified on Tuesday, February 26, 2008 3:36 PM

              J Offline
              J Offline
              Judah Gabriel Himango
              wrote on last edited by
              #6

              You could try Batch to see if it solves anything, might be interesting to note. FWIW, we've had a problem with the garbage collector here where our server app will use 500-700MB of memory before the garbage collector kicks in and brings it back down to 80MB. We've even had occassions where the app will be eating 1GB+ of memory and starts throwing OutOfMemoryExceptions until we force a GC. It's really insane. Unfortunately, the only way we were able to get around this is to force a GC key spots in the code. This isn't typical -- we've never seen the above issue on any other applications, so it may be a bug in our code somehow... We shouldn't have to do this, and sometimes I wonder if the GC is being too lazy, or in the above case, not working at all. Oddly, if I force 1 or 2 garbage collections, the GC seems able to handle everything from there on out. I guess I'd recommend forcing a GC in rare scenarios like the one you describe above, where lots of memory suddenly is freed and should be collected immediately.

              Tech, life, family, faith: Give me a visit. I'm currently blogging about: Upon this disciple I'll build my new religion? The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

              J 1 Reply Last reply
              0
              • J Judah Gabriel Himango

                You could try Batch to see if it solves anything, might be interesting to note. FWIW, we've had a problem with the garbage collector here where our server app will use 500-700MB of memory before the garbage collector kicks in and brings it back down to 80MB. We've even had occassions where the app will be eating 1GB+ of memory and starts throwing OutOfMemoryExceptions until we force a GC. It's really insane. Unfortunately, the only way we were able to get around this is to force a GC key spots in the code. This isn't typical -- we've never seen the above issue on any other applications, so it may be a bug in our code somehow... We shouldn't have to do this, and sometimes I wonder if the GC is being too lazy, or in the above case, not working at all. Oddly, if I force 1 or 2 garbage collections, the GC seems able to handle everything from there on out. I guess I'd recommend forcing a GC in rare scenarios like the one you describe above, where lots of memory suddenly is freed and should be collected immediately.

                Tech, life, family, faith: Give me a visit. I'm currently blogging about: Upon this disciple I'll build my new religion? The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

                J Offline
                J Offline
                Jitse
                wrote on last edited by
                #7

                Alright, seems the GC isn't 100% perfect yet. Thanks for the reply.

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups