Take the 2-minute tour ×

I am trying to write some code that works on both Linux and Win32. The most noticeable difference I find between them (in my code) is performance of fopen().
Following code takes 5 sec on my Ubuntu and the same code takes more than 100 sec on windows XP. I would like to make a note here that ubuntu is VM while XP is on a real machine.

    time_t start = time(NULL);
        FILE *fp = fopen("a.txt", "a");
        if (fp != NULL)
            fprintf(fp, "Hello World");
    time_t end = time(NULL);

    printf("\n It took %d seconds \n", end-start);

Clearly fopen() is the cause of this difference. I want to know why is it such a big difference?

share|improve this question
Your question is tagged C++. Did you try using iostreams? –  DeadMG Jul 20 '10 at 23:30
It was by mistake, thanks for pointing out. –  vrrathod Jul 21 '10 at 0:10
add comment

6 Answers

up vote 9 down vote accepted

Clearly fopen() is the cause of this difference

No it's more likely to be filesystem flushing.
On one system when you write, or more likely call fclose(), it blocks until the bytes are physically on disk (or at least until the disk says they are) - on the other the filesystems returns straight away, even if the flies are still being written

share|improve this answer
Yup you are absolutely right. my assumption is completely wrong about fopen(). I removed fclose() just to test this and it was at par on windows. –  vrrathod Jul 21 '10 at 0:08
@vrrathod: Although Martin is probably right, omitting fclose() still isn't a good test -- for one thing, you will exhaust the open file limit (on both OSes) and then the if statement won't be executed. –  j_random_hacker Jul 21 '10 at 0:27
You could also put an fflush() before the fclose() on both of them. It's not guaranteed though - the FS can pretty much do what it wants –  Martin Beckett Jul 21 '10 at 0:33
And the caching of files/streams is totally differen. Linux will be a lot faster if it has more RAM. The filesystem (VAT,NTFS,EXT3,XFS,...) should be considerd too: oracle.com/technology/tech/linux/pdf/… –  Andreas Rehm Jul 21 '10 at 6:30
add comment

Do you use a Virus Scanner? If yes disable it first!

And some API Calls are slower on windows. E.G. your C:\ will be translated to /harddrive/something first (just an example).

share|improve this answer
This is a very valid reason, even if it may turn out not to apply in this particular case. I saw a post recently where Windows' networking performance compared abysmally with Linux's, but the disparity disappeared when Windows Firewall was turned off. –  j_random_hacker Jul 21 '10 at 0:29
I agree this seems plausible, possibly even likely. –  MarkR Jul 21 '10 at 16:14
add comment

There is a lot more than just the API being used here.

You are opening a file on the file system.
So the type of file system being used will affect time, as well as the hard ware speeds of the devices implementing the file system. There are just too many factors that you are not taking into account that you can accurately say X is the culprit for the slow speeds.

share|improve this answer
add comment

If you are using Visual C++, be aware that by default stdio now uses mutexes to enable safe multithreading. These can be turned off with #define _CRT_DISABLE_PERFCRIT_LOCKS. [EDIT 31/12/2013] I'm not certain, but I think Linux stdio implementations usually assume single-threaded behaviour, so don't have this locking overhead. Linux stdio implementations likewise obey POSIX and C11 standards that require safe multithreading, providing lock-free versions of functions whose names end with _unlocked, e.g. fgetc_unlocked().

More info here: http://msdn.microsoft.com/en-us/library/ms235505%28v=VS.80%29.aspx

share|improve this answer
And take a look at this msdn.microsoft.com/en-us/library/eadhs8bd%28VS.80%29.aspx –  Matt Joiner Jul 21 '10 at 0:23
Linux implementations of stdio are thread-safe as mandated by the standard. That's why there is a whole set of APIs like fread_unlocked. –  strcat Dec 30 '13 at 22:48
@strcat: The only standard I could find regarding thread safety of stdio is the POSIX standard, mentioned here: stackoverflow.com/a/3335444/47984. Is it part of C99 or C11? (Note that this answer was posted in 2010.) –  j_random_hacker Dec 31 '13 at 1:07
Threading wasn't part of C until C11, so the wording wasn't added until then. Linux and other *nix operating systems implement POSIX though. –  strcat Dec 31 '13 at 14:09
@strcat: I've made some edits. If you have a good link for the C11 standard, please add it in -- I couldn't find anything very definitive with Google. –  j_random_hacker Dec 31 '13 at 18:04
add comment

This isn't relevant. This is not a normal usage scenario for I/O functions, so they don't have to be optimized for this case. Maybe windows uses an syncronous flush() while linux uses asyncronous.

share|improve this answer
add comment

I would do the following:

  1. Try it on a real hardware machine similar spec to the intended target
  2. Use the same machine on the Windows and Linux tests - dual boot it or something.
  3. Disable all third party add-ons on the windows box, especially AV software (NB: If your company IT department does not allow this, explain to them that this is a software development lab machine and need not be subject to their policy if suitably separated from the main office network)

In all likelihood they are not doing the same thing. The filesystem is probably responsible. Either the win32 box is doing a lot more flushing - possibly because it has less ram available due to other tasks - or the Linux box is running on hardware which fakes flushing and introduces another level of caching - i.e. cheats.

What level of durability do you require in your application? If the files absolutely must not disappear on power failure (e.g. mail server receiving mail) then you should fsync() them. fclose() does not guarantee to do this

share|improve this answer
add comment

Your Answer


