Performances de fopen() sur win32

Question

J'essaie d'écrire un code qui fonctionne à la fois sous Linux et Win32. La différence la plus notable que je trouve entre eux (dans mon code) est la performance de fopen() .
Le code suivant prend 5 secondes sur mon Ubuntu et le même code prend plus de 100 secondes sur Windows XP. Je tiens à préciser ici qu'Ubuntu est une VM alors que XP est sur une vraie machine.

    time_t start = time(NULL);
    for(int i=0; i < 100000; ++i){
        FILE *fp = fopen("a.txt", "a");
        if (fp != NULL)
        {
            fprintf(fp, "Hello World");
            fclose(fp);
        }
    }
    time_t end = time(NULL);

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

Clairement fopen() est la cause de cette différence. Je veux savoir pourquoi cette différence est si importante.

Answer 1

Il est clair que fopen() est à l'origine de ce problème. différence

Non, il est plus probable que ce soit le vidage du système de fichiers.
Sur l'un des systèmes, lorsque vous écrivez, ou plus vraisemblablement lorsque vous appelez fclose(), le système bloque jusqu'à ce que les octets soient physiquement sur le disque (ou du moins jusqu'à ce que le disque indique qu'ils le sont) - sur l'autre système de fichiers, le retour est immédiat, même si les mouches sont toujours en cours d'écriture.

Answer 2

Utilisez-vous un scanner de virus ? Si oui, désactivez-le d'abord !

Et certains appels d'API sont plus lents sous Windows. Par exemple, votre C:\ sera d'abord traduit en /harddrive/something (juste un exemple).

Answer 3

Il y a beaucoup plus que l'API utilisée ici.

Vous ouvrez un fichier sur le système de fichiers.
Ainsi, le type de système de fichiers utilisé aura une incidence sur le temps, de même que la vitesse des disques durs des périphériques qui mettent en œuvre le système de fichiers. Il y a trop de facteurs que vous ne prenez pas en compte pour que vous puissiez dire avec précision que X est le coupable de la lenteur des vitesses.

Answer 4

Si vous utilisez Visual C++, sachez que stdio utilise par défaut les mutex pour permettre un multithreading sécurisé. Ceux-ci peuvent être désactivés avec #define _CRT_DISABLE_PERFCRIT_LOCKS . [EDIT 31/12/2013] Je ne suis pas certain, mais je pense que les implémentations stdio de Linux supposent généralement un comportement monofilaire, et n'ont donc pas cette surcharge de verrouillage. Les implémentations stdio de Linux obéissent de même à POSIX et C11 qui exigent un multithreading sûr, en fournissant des versions sans verrou des fonctions dont les noms se terminent par _unlocked par exemple fgetc_unlocked() .

Plus d'informations ici : http://msdn.microsoft.com/en-us/library/ms235505%28v=VS.80%29.aspx

Answer 5

Ce n'est pas pertinent. Ce n'est pas un scénario d'utilisation normal pour les fonctions d'E/S, donc elles n'ont pas besoin d'être optimisées pour ce cas. Peut-être que Windows utilise un flush() synchrone alors que Linux utilise un flush() asynchrone.