Performances de malloc/free + fgets en C

Question

Lorsque je passe en boucle les lignes du fichier A, j'analyse la ligne et je place chaque chaîne ( char* ) en un char** .

En fin de ligne, je lance alors une procédure qui consiste à ouvrir le fichier B, en utilisant fgets , fseek y fgetc pour récupérer les caractères de ce fichier. Je ferme ensuite le fichier B.

Je répète la réouverture et la refermeture du fichier B pour chaque ligne.

Ce que je voudrais savoir, c'est :

1. Est-ce que l'utilisation de malloc y free de sorte que je devrais utiliser quelque chose de statique comme myArray[NUM_STRINGS][MAX_STRING_WIDTH] au lieu d'un char** myArray ?

2. L'ouverture et la fermeture du fichier B (en principe, plusieurs milliers de fois) entraînent-elles une surcharge importante des performances ? Si mon fichier A est trié, y a-t-il un moyen pour moi d'utiliser fseek pour revenir en arrière dans le fichier B, pour réinitialiser l'endroit où je me trouvais précédemment dans le fichier B ?

EDIT Il s'avère qu'une double approche a permis de réduire considérablement le temps d'exécution :

1. Mon fichier B est en fait un des vingt-quatre fichiers. Au lieu d'ouvrir le même fichier B1 des milliers de fois, puis B2 des milliers de fois, etc. j'ouvre le fichier B1 une fois, je le ferme, B2 une fois, je le ferme, etc. Cela réduit de plusieurs milliers de fopen y fclose à environ 24.

2. J'ai utilisé rewind() pour réinitialiser le pointeur de fichier.

Cela a permis de multiplier la vitesse par 60 environ, ce qui est plus que suffisant. Merci de m'avoir indiqué rewind() .

Answer 1

1. Je pense qu'il est préférable d'allouer l'élément l'espace dont vous avez besoin, et la et la surcharge ne sera probablement pas significatif. Cela permet d'éviter à la fois le gaspillage d'espace et les débordements de pile

2. Oui. Bien que l'entrée-sortie soit mise en cache, vous faites des appels syscall inutiles (open et close). Utilisez fseek avec probablement SEEK_CUR o SEEK_SET .

Answer 2

Dans les deux cas, il y a algunos Les performances sont affectées, mais l'importance dépend de la taille des fichiers et du contexte dans lequel votre programme s'exécute.

1. Si vous connaissez le nombre maximal de chaînes et la largeur maximale, cela sera beaucoup plus rapide (mais vous risquez de gaspiller beaucoup de mémoire si vous utilisez moins que le "max"). Le juste milieu est de faire ce que beaucoup d'implémentations de tableaux dynamiques en C++ font : chaque fois que vous devez réallouer mon tableau, allouez deux fois plus d'espace que nécessaire, et ne réallouez à nouveau qu'une fois l'espace épuisé. Ceci a un coût de performance de O(log n).

2. Cela peut être un gros problème de performance. Je recommande fortement d'utiliser fseek, bien que les détails dépendent de votre algorithme.

Answer 3

Je trouve souvent que le surcoût de performance est plus important que la gestion directe de la mémoire qu'offre le système malloc et ces gestionnaires C de bas niveau sur la mémoire. À moins que ces zones de mémoire ne restent statiques et intactes pendant une durée supérieure à celle de la manipulation de cette mémoire, il peut être plus avantageux de s'en tenir au tableau statique. En fin de compte, c'est vous qui décidez.