Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>As many have mentioned, this is probably just an artifact of the GC not cleaning up the memory storage as fast as you are expecting it to. This is normal for managed languages, like C#, Java, etc. You really need to find out if the memory allocated to your program is free or not if you're are interested in that usage. The questions to ask related to this are:</p> <ol> <li>How long is your program running? Is it a service type program that runs continuously?</li> <li>Over the span of execution does it continue to allocate memory from the OS or does it reach a steady-state? (Have you run it long enough to find out?)</li> </ol> <p>Your code does not look like it will have a "memory-leak". In managed languages you really don't get memory leaks like you would in C/C++ (unless you are using <em>unsafe</em> or external libraries that are C/C++). What happens though is that you do need to watch out for references that stay around or are hidden (like a Collection class that has been told to remove an item but does not set the element of the internal array to <code>null</code>). Generally, objects with references on the stack (locals and parameters) cannot 'leak' unless you store the reference of the object(s) into an object/class variables.</p> <p>Some comments on your code:</p> <ol> <li><p>You can reduce the allocation/deallocation of memory by pre-allocating the <code>StringBuilder</code> to at least the proper size. Since you know you will need to hold the entire file in memory, allocate it to the file size (this will actually give you a buffer that is just a little bigger than required since you are not storing new-line character sequences but the file probably has them):</p> <pre><code>FileInfo fi = new FileInfo(path); StringBuilder fb = new StringBuilder((int) fi.Length); </code></pre> <p>You may want to ensure the file exists before getting its length, using <code>fi</code> to check for that. Note that I just down-cast the length to an <code>int</code> without error checking as your files are less than 2GB based on your question text. If that is not the case then you should verify the length before casting it, perhaps throwing an exception if the file is too big.</p></li> <li><p>I would recommend removing all the <code>variable = null</code> statements in your code. These are not necessary since these are stack allocated variables. As well, in this context, it will not help the GC since the method will not live for a long time. So, by having them you create additional clutter in the code and it is more difficult to understand.</p></li> <li><p>In your <code>ParseMessages</code> method, you catch a <code>NullReferenceException</code> and assume that is just a non-text node. This could lead to confusing problems in the future. Since this is something you expect to normally happen <em>as a result of something that may exist in the data</em> you should check for the condition in the code, such as:</p> <pre><code>if (node.Text != null) sb.Append(node.Text.Trim()); //Name </code></pre> <p>Exceptions are for exceptional/unexpected conditions in the code. Assigning significant meaning to <code>NullReferenceException</code> more than that there was a null reference can (likely will) hide errors in other parts of that same <code>try</code> block now or with future changes.</p></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload