Discussion :

[Orkhidion]

Voila je vous explique mon souci,

jai un programme qui cherche dans des fichiers des mots clefs et cela sur tout le disque dur (je precise je suis sur Linux, dont recursivite et autre).

Le programme fonctionne tres bien mais lorsqu il attaque les fichiers "gros", j entends par la les fichiers superieurs a 2Go et bien il est super lent :S, mais il fonctionne par exemple pour du fichier de 1Go il me met 7min . Pour faire la recherche je fread en boucle le fichier et j analyse le buffer avec memcmp.

Pour la gestion des fichiers superieurs a 2Go j utilise les fonctions fseeko, ftello.

Je voudrais savoir si vous connaissiez une taille de buffer optimale pour que ca se fasse vite ou sinon serais-ce plus rapide si j y allais a coup tout simple de lseek ?

Merci pour votre aide d avance

[souviron34]

euh...

Sur un système unixoide, pourquoi ne pas utiliser grep ??

[Orkhidion]

Car je recherche en bas niveau dans les fichiers

[Obsidian]

Car je recherche en bas niveau dans les fichiers

GREP est capable de lire des fichiers binaires (si c'est ce que tu entends par « bas niveau »). La version GNU, en tout cas. Quelle taille de buffer utilises-tu ? Est-ce que tu prends en compte les cas où un motif se retrouve à cheval sur deux blocs consécutifs ?

Sinon, d'une manière générale, tu peux utiliser mmap() pour mapper un fichier en mémoire. C'est ce qu'il y a de plus simple, et de plus rapide également car c'est le système qui gère les accès comme il l'entend.

[Orkhidion]

Ce que j'entends par bas niveau c'est pas exemple checker les headers des fichiers et autres.

Pour mmap si par exemple notre fichier fait 12Go et que l'on a que 2Go en memoire ca fonctionne tout de meme ?

[Jenna]

Pour mmap si par exemple notre fichier fait 12Go et que l'on a que 2Go en memoire ca fonctionne tout de meme ?

Oui et c'est même le gros avantage. Tu n'as pas a te soucier de la taille du fichier, c'est le système qui le gère pour toi