2010-10-07 19 views
1

J'ai une application qui va télécharger et mettre en cache, au minimum, 250 000 fichiers de 8 Ko * totalisant environ 2 Go. J'ai besoin de supprimer le fichier le moins récemment utilisé lors de la mise à jour de ce cache. * Ces fichiers minuscules couvrent deux secteurs de 4 Ko.Cache de fichiers LRU et coût de recherche d'un fichier dans un répertoire Windows

Quel est le coût relatif d'obtenir un nom de fichier par nom pour ce type de fichier dans un répertoire sur un lecteur 5400 RPM NTFS? Si je stocke tous les fichiers de 200 Ko dans un répertoire, l'obtention d'un handle de fichier prendra plus de quelques millisecondes? Je peux facilement placer les fichiers dans des répertoires différents. Windows 7 désactive la dernière heure d'accès aux fichiers par défaut et je ne souhaite pas qu'un administrateur active cette fonction. Dois-je conserver une liste séparée des heures d'accès aux fichiers en mémoire (sérialisé sur le disque lorsque l'application se ferme?)

Dois-je envisager de stocker ces fichiers dans un grand fichier plat? Le mappage de la mémoire peut être difficile si j'utilise quelque chose de plus ancien que .NET 4.0

Répondre

1

L'ouverture de 250 000 fichiers - si c'est ce que vous voulez dire - prendra plus de quelques millisecondes, oui. La taille du répertoire est moins intéressante que le fait que vous parcourez 250 000 fois la totalité de la pile du système de fichiers (tout depuis NTFS, le noyau et le filtre anti-virus préféré de votre grand-mère doivent avoir une chance de jouer).

Et le dernier temps d'accès n'est en aucun cas solide comme le roc.

+0

J'ai seulement besoin d'ouvrir un de ces fichiers en quelques millisecondes, pas tous. J'essaye de comprendre si c'est si cher d'ouvrir un fichier dans un répertoire très peuplé. Cela vaut-il la peine de créer des sous-répertoires si j'ai 250K fichiers dans un répertoire? –

+0

Le seul surcoût ajouté est dans les opérations d'index, c'est-à-dire faire la recherche dans l'index du répertoire. L'index est un arbre B, donc la recherche est O (log (n)), qui est d'environ 17. Donc, subjectivement, je dirais que vous êtes probablement bien. – jrtipton

+0

En fait, je dois préciser que l'énumération du répertoire et l'insertion de nouveaux fichiers peuvent être compliquées si la génération de noms courts n'est pas désactivée et que les fichiers ont des noms longs. Je faisais juste référence à l'affaire ouverte. – jrtipton

1

Une recherche est d'environ 15ms sur un lecteur 5400rpm en moyenne. Le reste est minuscule en comparaison.

+0

Je vous recommande également de placer les fichiers dans des compartiments de 2000-3000 fichiers chacun. – GregC

+0

Je pense aussi que l'utilisation de n'importe quelle base de données décente pourrait être utile au lieu de répertoires/fichiers plats. – GregC

+0

Utilisez Firefox comme motivation. Ils traitent beaucoup de petits fichiers du côté client ... SQL Lite est utilisé pour stocker l'historique et le cache de fichiers. Internet Explorer traite les fichiers dans plusieurs chutiers. Nuf a dit. – GregC