It is definitely more efficient to write to a file in as large a block as possible. The limiting factor in terms of speed when writing files is the latency of the hard drive - it takes time to locate the sector on the disk to write to, and this takes much much longer than any other task in terms of writing data. You want to take advantage of the current location of the disk head, and write as much data as possible where it is. If you write continuously to a file in a seperate step via multiple loop iterations, that is the slowest possible way to do it.
That being said, most modern OS, including windows, already buffer their file system. That is, when you make a platform-specific OS file write call, you're really not writing directly to the disk, you're writing to a block of RAM, which will be very fast. When the buffer is full,it is then flushed to the drive.
On top of this, you can create your own buffer in
java. You are doing so by writing everything to a StringBuffer first. Another way to do it is simply use a BufferedOutputStream. It will let you buffer your output and use the same OutputStream API, and you won't have to do something special like write to a StringBuffer.
There may be good reasons for doing what you are doing, especially if you need to pre-fill a buffer quickly, but then do some processing on that buffer before you finally send it to the OutputStream. I don't know if you are doing this or not.
You will have a slight performance hit when you copy the StringBuffer data to a String object via the toString() method. If the data in the STringBuffer is small, and you are not writing it that often, this extra step will probably not be noticeable. However, if you're filling your STringBuffer with a lot of data in a loop that gets executed many times, this extra step may become a performance bottleneck. It really depends on your particular programming situation.
I would take a look at using a BufferedOutputStream and compare the speed and code required to do it each way, just to get a sense of what some alternatives are.