fopen

Is it going to a be an great impact on the performace of the system if opeing a text file and closing quite offen? I mean what happens when i call fopen. I think it traps the OS to open a file and to write and at last to close a file. If that was the case why not use open/close to all i/o file operations?

Thank you

ssharish

The performance impact is, like so many other things, system-specific. If you're worried about it, you can profile the code (using callgrind on Linux, perhaps other x86 unix systems, for example).

fopen() and fclose() are portable to all (hosted) ANSI/ISO-conforming implementations. open() and close() are not; they're POSIX (and, quite probably, others).

On POSIX systems fopen() and fclose() will use open() and close(), sure. They're not the same, though: the ISO FILE* routines are, by default buffered. Maybe this is good for you, maybe not.

Basically, if you want maximally portable code, use FILE*. If you are targeting POSIX and have a need for unbuffered file operations, perhaps you'd want to do things with file descriptors instead. As usual, it comes down to choosing what's right for a particular task.

FWIW

Opening and closing files is definitely on the "expensive" list of calls you can make - how expensive will depend on many different things - the filesystem type, the storage media, etc, etc.

Opening the same file over and over again is slightly better than opening different files, because the localtion of the file, etc, can (and will) be cached by the OS.

But it's certainly better to open the file once, write to it many times, and then close it - at least if this is something that happens many times a second. If it's a log-file written to once a minute or so under normal circumstances, then you may just as well open and close it when you write to it - it's not going to make any difference to the overall application performance.

And yes, the summary of how it works is fair: fopen calls the OS "open"[1] function which is some sort of trap-type function to get to the kernel, and inside the kernel there's a chain of generic code calling the file-system driver for the relevant storage, followed by device driver code to access the drive itself. In this particular case, it's quite a bit of work inside the OS - the actual trap into the OS is relatively small in comparison.

[1] OpenFile in Win32, open() in Linux.

--
Mats

Thanks a lot every one. It had been much helpful. Matsp and yes you guessed it right, i am in the process of creating a log file in which the file could be opened and closed quite frequently.

Hence i was more concerned about the performs. And this system is suppose to run on embedded broad and I don't want to give too much stress to the process and the OS since the process works with max spreed of up to 200 MHz.

And ya, even i through of keeping the file opened all the time. If I need reading it anyway i could create a new stream in a read mode. The way it works is , there is a background process running at all the time which gets all the data from other process which need writing. Since only this process had opened the file in write mode. All other should send the data to this process to write on to the file.

This way I could control opening the file many time and so on. The problem which i have got is that, i keep on writing the data on to the file. But when I read it from the file through a different process. It looks like nothing has written on to the file. And found why, since the file wasn't closed nothing was updated to the file.

Is that true if you don't close the file after u write. The contact wouldn't get updated to the file unless it is closed?

Thanks again everyone for your help

ssharish

If you want to ensure that the file is "upto date", use fflush() - that's what the this function is for.

If you are dealing with the file at a lower level, you may be able to do O_DIRECT as well, which essentially tells the OS "don't buffer this".

Flushing, and using O_DIRECT may have performance impact - the latter is better for really large writes under the right conditions [1] and worse if you do lots of small writes. Flushing will almost certainly reduce the throughput, but it will do that LESS than opening and closing the file lots.

[1] This is similar to using non-temporal writes on a processor to bypass using the cache - it's faster to do this when you will "run out of" cache anyways - e.g. if you are filling 2MB of RAM on a machine with 256KB of L2 cache, it's hardly much point in filling the cache with 256KB, and then replace that with the next 256KB and so on - might just as well get the processor to write directly to memory without passing it through the cache - particularly as a write to the cache enforces a read of the remaining cache-line, to ensure that the cache-line is always complete.

--
Mats