BackgroundWorker and its ReportProgress(..) method. Unnecessary heap burden ? RRS feed

  • General discussion

  • I use the BackgroundWorker class from time to time and in a recent application, I was a bit troubled when I dug into the inner workings of its ReportProgress method.  On the surface, this seems to be an innocuous method, but if you look at it with Reflector, you'll see that the method instantiates a new ProgressChangeEventArgs object every time it's called.

    Now, calling this method a few times or even dozens wouldn't be much of an issue, but consider my case:  I'm using the background worker to upload 128K bytes to an external device, 32 bytes at a time ... each time through the loop of course it's easy ( again, on the surface ) to call ReportProgress(..).  In doing so, however, the total upload process would instantiate 4096 ProgressChangeEventArgs objects.  Isn't that kinda punishing the heap ?  Granted, ProgressChangeEventArgs is a relatively small object, but still the same ...

    I will admit I don't have a great understanding of the inner workings of the garbage collector, or if C# / .NET is smart enough to "reuse" objects, but regardless that seems like an awful lot of objects being instantiated.

    Am I worried over nothing?


    Thanks for your input.


    Thursday, July 21, 2011 4:43 PM

All replies

  • Once an object goes out of scope and has no subscribed events to it, it is automatically tagged for garbage collection so yes it is efficient.

    A program can run through literally hundreds of thousand of objects during its lifetime. Each object created is a specific timeshot of the current operation and has its required need by the ultimate consumer. I surmise writing a single manager to handle the task would involve more code due to the complexity and having a throw away object (wrong connotation) is truly the best for this process; as you intimate the garbage collector handles that and provides the memory to the application as it runs so it won't affect overall performance.

    Regardless I recommend that you profile the application as it runs. If it requires too much memory per your requirements, either quit using the operation, or write a manager to only queue up a new progress event every second or so and not allow multiple to go through which may not be properly consumed due to the time constraints of a human reading the status.


    William Wegerson (www.OmegaCoder.Com)
    Thursday, July 21, 2011 5:01 PM
  • If the GC can handle it, then I guess I'm not too concerned.  As you said, any particular program can go through countless objects during its lifetime.  I was concerned mostly because unlike the (relatively) long lifetime of a program, this loop runs fast and would pound the heap with those thousands in a very short time ( seconds ).

    What I failed to mention is that I do a LOT of embedded programming and as such I have a natural tendency to be considerate of memory consumption.  Further, the application in question may get ported to a memory-limited embedded platform.

    I agree with your second paragraph, tho.  I could profile it ... if for nothing else just out of curiosity.  Is there a namespace that provides profiling classes ?


    Thanks for the response.


    Thursday, July 21, 2011 6:18 PM
  • Thursday, July 21, 2011 6:53 PM
  • ReportProgress is designed to report back to the UI thread with a Post message.  You shouldn't send messages more freqently than the UI thread can update, typically 20 times per second.  Does your upload take at least 3 minutes?  Even if it does, you might consider reducing the number of updates to once every 2K or 4K bytes.
    Thursday, July 21, 2011 8:42 PM
  • I kinda figured that's what it was doing with the AsyncOperation(..).

    My upload doesn't take that long, but I currently fire a progress report each time through the loop.  It was the easy/intuitive way to do it ... you understand.  I suppose it wouldn't be too difficult to limit the number of reports fired, but having to do that kinda makes using ReportProgress akin to an automatic transmission that still requires a clutch pedal to shift.

    Thursday, July 21, 2011 9:47 PM