OK, so on the face of it you are creating three copies, two of which are at least twice the size of the byte array. First you read all the bytes into an array, which can't be smaller than the file. You then convert that byte array to a string array. That doesn't remove the byte array, it's still there, but now you have a second array of strings, which also can't be smaller than the original file, and is likely at least twice as large, and possibly four times as large (a byte is a byte, but a byte represented as a string has to be two characters, which are either one byte each or two bytes each, so the string array has to be either twice or four times the size of the byte array). Finally, you join that string array into one giant string and put it in the RTB. That joined string can't be smaller than the string array. In fact, you may be creating two different strings in this step, so there may be a fourth copy in there. The Join may create a string that is then copied into the RTB, in which case there's a fourth, temporary, intermediate.

That's a fair amount of memory being used up. The temporary objects, which are the byte array and the original string array, will not be destroyed, but they should be flagged for destruction once the method completes. While the method is running, you'd be using a HUGE amount of memory, but once that method is finished, it should be possible to recover that memory.

The clear solution is to avoid all the intermediates. I'm not sure what would be efficient for doing that, but ReadAllBytes seems like it would be the wrong way to start out. If you were to read the file byte by byte, you could convert each byte as it comes in. If you did that, and attached each to a string, that would be truly horrible, since strings are immutable, so each byte would require a new string as long as the old one plus the size needed for the next byte. That would be a staggering amount of memory. However, using a StringBuilder, which is essentially a mutable string, should remove that cost.

It's quite likely that others can suggest a more efficient approach than that, too. It's not a problem I have ever tried to solve. I can lay out the cost of the way you are doing it, simple though it is, but what the most efficient alternative is I can't say.