We have a Log class which write log entries into a log file via StreamWriter. Each time when its logItem() is called, an entry will be passed in and write to the file. Right now after the WriteLine() method call, a Flush() is also called.
Do you think it is necessary to call Flush() for each write? any performance impact?
It will reduce performance a lot.
It is always better to use AutoFlush, because it is optimized and fast, and doesn't need a lot of code to do the job.
if you are not going to use autoflush, flushing every 50 or 60 lines will give you better performance, but the number depends on line lengths(usually 4KB is OK for every flush)
a better way is using a binary protocol and use some code to read it, it is always faster with no condition.
Obviously, there's a performance impact. The real question is, is there enough of a performance impact to matter. And (although we can't really tell from your question) most likely there isn't.
It really depends on how many lines are getting written to the log, and how expensive writing to the stream is (a faster file system will be less expensive). The only way to know is to test it, under the conditions you expect it to be running.
Whether it's necessary to call Flush() depends on how up-to-date you need the log to be. If you're worried about losing data if the system crashes, you need to call it often (especially if the log is going to be used to help debug the crashes). A compromise might be to keep a counter and flush the log every 4 or 5 lines or so.
In short: I'd keep it flushing the data every line, for now. Once you've finished the program, you can profile the code to see what's causing it to run slowly. If it's the log, then worry about making it faster. Not before.
Well, the call to Flush does exactly what it says it will. Streams will buffer information for the sake of performance; more often than not, it's easier to get larger packets of bytes and then write that to the underlying resource (disk, network) than it is to perform a write to the underlying resource every time.
Calling Flush will ensure that whatever is buffered is written to the underlying resource.
If you are calling this after every write, you will probably see a decrease in performance, because you are making many little writes to what I assume is the disk. The benefit here is that it is more fault tolerant. If something crashes, your log will be as up to date as possible.
If you don't call Flush after every write to the log, then you run the risk of losing some of that information in the face of a fault.
Now, whether or not the tradeoff is necessarily a good one is up to you, you have to measure the impact of calling Flush either all the time, or at various other times, and whether or not it meets your risk and performance needs.
Performance of this issue is something that can be easily tested.
Flush will have a performance impact, but it will not necessarily cause contents to be written to disk immediately (the biggest potential performance impact) unless you have specified FileOptions.WriteThrough, or the OS has been specifically configured not to use write-caching for the target disk. If FileOptions.WriteThrough has not been specified, data will be written\buffered to the OS disk cache (i.e. memory), and then written to disk by the OS at some later point in time i.e. asynchronously.
So although there are potential performance problems, these may be mitigated to an extent by the OS disk cache which will buffer writes and then commit them at some later point in time. However, this does bring in reliability issues, as uncommitted log entries could be lost if the application crashes.
You need to balance performance with reliability needs.
Actual performance characteristics could depend largely on your: hardware, environment\settings and your logging behaviour. Test the performance first and then think about simple optimizations if there is actually an issue e.g. only flush after so many lines, bearing in mind reliability issues.
"Don't think - measure".