I have to write thousands of dynamically generated lines to a text file. I have two choices, Which consumes less resources and is faster than the other?
A. Using StringBuilder and File.WriteAllText
StringBuilder sb = new StringBuilder();
foreach(Data dataItem in Datas)
{
sb.AppendLine(
String.Format(
"{0}, {1}-{2}",
dataItem.Property1,
dataItem.Property2,
dataItem.Property3));
}
File.WriteAllText("C:\\example.txt", sb.ToString(), new UTF8Encoding(false));
B. Using File.AppendText
using(StreamWriter sw = File.AppendText("C:\\example.txt"))
{
foreach (Data dataItem in Datas)
{
sw.WriteLine(
String.Format(
"{0}, {1}-{2}",
dataItem.Property1,
dataItem.Property2,
dataItem.Property3));
}
}
Your first version, which puts everything into a StringBuilder
and then writes it, will consume the most memory. If the text is very large, you have the potential of running out of memory. It has the potential to be faster, but it could also be slower.
The second option will use much less memory (basically, just the StreamWriter
buffer), and will perform very well. I would recommend this option. It performs well--possibly better than the first method--and doesn't have the same potential for running out of memory.
You can speed it quite a lot by increasing the size of the output buffer. Rather than
File.AppendText("filename")
Create the stream with:
const int BufferSize = 65536; // 64 Kilobytes
StreamWriter sw = new StreamWriter("filename", true, Encoding.UTF8, BufferSize);
A buffer size of 64K gives much better performance than the default 4K buffer size. You can go larger, but I've found that larger than 64K gives minimal performance gains, and on some systems can actually decrease performance.
You do have at least one other choice, using File.AppendAllLines()
var data = from item in Datas
select string.Format("{0}, {1}-{2}", item.Property1, item.Property2, item.Property3);
File.AppendAllLines("Filename", data, new UTF8Encoding(false));
This will theoretically use less memory than your first approach since only one line at a time will be buffered in memory.
It will probably be almost exactly the same as your second approach though. I'm just showing you a third alternative. The only advantage of this one is that you can feed it a Linq sequence, which can be useful sometimes.
The I/O speed will dwarf any other considerations, so you should concentrate on minimising memory usage as juharr noted above (and also considering the dangers of premature optimisation, of course!)
That means using your second approach, or the one I put here.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With