I'm not sure if I'm just not doing this right or if there is a leak in DynamicByteProvider, but memory can explode to over 2GB when using the DynamicByteProvider instead of DynamicFileByteProvider.
Take the following function for example:
private void LoadHexViewer(byte data)
if (hexViewer.ByteProvider != null)
IDisposable byteProvider = hexViewer.ByteProvider as IDisposable;
if (byteProvider != null)
hexViewer.ByteProvider = null;
hexViewer.ByteProvider = new Be.Windows.Forms.DynamicByteProvider(data);
If I call LoadHexViewer(data) code 2-3 times (assuming data is a buffer of about 15mb), the memory usage will expand to and remain at ~500mb. Continually executing this code will cause it to expand over 2GB.
To insure this wasn't something in my code, I modified the OpenFile() function in FormHexEditor.cs of the HexBox source code. I commented out lines 139-167 where a DynamicFileByteProvider is created and substituted it with the following code:
byte readdata = File.ReadAllBytes(fileName);
hexBox.ByteProvider = new DynamicByteProvider(readdata);
_fileName = fileName;
Sure enough, loading a ~30mb file instantly caused the memory usage to explode over 1GB.
Not sure if I'm just misusing the DynamicByteProvider type or if there is a real problem here, but I'd appreciate any clarification.
I did some tests and confirm this behaviour. It relies on the internals of DynamicByteProvider that is using the ByteCollection object to store the bytes in memory. This collection does not implement IDisposable, but you can improve memory management if you implement IDisposable in DynamicByteProvider class…
public void Dispose()
_bytes = null;
Additionally you can put an GC.Collect() after a new DynamicByteProvider is created.
However the best way would be replacing the ByteCollection with List<Byte> class that is having a much better performance and memory management. I will do this change in the release of Be.HexEditor.
Thank you for reporting this.