3

I need to use some 75 (small) .wav files in my Winforms C# application and was wondering which system is more efficient (memory wise) - loading a .wav from a file and playing the sound or using embedded resources?

If I use the file method, I take it the memory would be freed-up after the sound has been played. If I use resources I believe these would not be freed-up until...

Mark Rogers
  • 96,497
  • 18
  • 85
  • 138
MartinHT
  • 289
  • 1
  • 9
  • 1
    Memory concerns aside: would you rather ship **one** Winforms app with embedded resources, or one Winforms EXE and 75 `.wav` files?? What if one or two of those `.wav` are missing or accidentally deleted? I would go with embedded resources just because of this *convenience* of having everything in a single `EXE` and not having to worry about shipping & finding 75 separate files! – marc_s Oct 02 '14 at 06:38

2 Answers2

4

An embedded resource is still just part of your compiled assembly file, and it is not loaded into memory when the assembly is loaded, it is loaded as required. So there's no real difference memory-wise.

Saeb Amini
  • 23,054
  • 9
  • 78
  • 76
  • Taking into consideration Jason'd comment on duplicated memory, it would seem the file is the way to go. Also once a file is finished I can free its memory, but the resource will stay in memory until the app closes, correct? – MartinHT Oct 02 '14 at 07:49
  • Okay, it seems the duplicate memory is not an issue (see comment to Jason's response), but freeing the file as opposed to the resource might be, depending on if resources can be freed-up without closing the application. – MartinHT Oct 02 '14 at 07:51
  • @MartinHT, just dispose the WAV after you're done with it and CLR's Garbage Collector will do its job and free the memory. – Saeb Amini Oct 02 '14 at 08:00
  • This contradicts what [Hans Passant](https://stackoverflow.com/users/17034/hans-passant) says in [this answer](https://stackoverflow.com/a/43549273/1364007). – Wai Ha Lee Oct 09 '20 at 09:22
0

If the wav is embedded in your application, the resource is built into the .exe and so gets loaded into RAM when required. When you then "open" the resource, the data is typically copied into a new block of RAM, so you end up with two copies (although in some cases you may be able to use the data directly from the resource stream without having to create an actual object, avoiding the second copy). A file may therefore be a more "memory efficient" approach.

However, bear in mind that even on a 32 bit PC you can use 2Gb per process, so unless your application has extreme RAM requirements, this inefficiency is irrelevant, and you may find the benefits of embedding outweigh the possible extra memory use.

Jason Williams
  • 56,972
  • 11
  • 108
  • 137
  • They don't get loaded into RAM, the resources will still be on the disk, but instead of being separate files, they are encapsulated by the .NET Assembly file and they will be loaded into memory when they are accessed. – Saeb Amini Oct 02 '14 at 07:42
  • @SaebAmini: I'm happy to be proven wrong, but [ResourceManager.GetStream](http://msdn.microsoft.com/en-us/library/zxee5096(v=vs.110).aspx) (for reading a resource from a loaded assembly) "Returns an unmanaged **memory** stream object from the specified resource" - i.e., it reads embedded data directly out of the loaded (RAM resident) assembly. Can you point at documentation that contradicts this? – Jason Williams Oct 02 '14 at 20:45
  • (However, it may be possible to stream a wav directly from the resource data, in which case it might be possible to avoid creating the *second* copy. I've updated my answer to reflect this) – Jason Williams Oct 02 '14 at 20:52