Quel est le moyen le plus rapide d'extraire des archives .zip? Les performances de mon application sont fortement basées sur la manière dont les fichiers .zip sont extraits. J'utilise ATM DotNetZip, mais il semble qu'il puisse y avoir des outils plus rapides. S'il y a, sont-ils en sécurité? J'ai entendu dire que le QuickLz est le plus rapide, mais je n'ai pas trouvé aucun échantillon de code ni comment l'utiliser dans C #. Toute aide serait grandement appréciée.
4 Réponses :
Quelle est la taille de vos fichiers ZIP? Peut-être que vous pouvez profiter des processeurs multicœurs modernes en divisant le fichier d'origine en parties, en zippant chaque partie de manière indépendante et en les décompressant dans votre application à l'aide de multithreading. Le temps de recombiner les fichiers en mémoire sera minuscule par rapport à la durée de décès.
Les fichiers zip sont autour de 500 Mo à 1,5 Go. Vous pensez donc que je devrais créer 2 fichiers zip d'origine, puis extraire chacun d'eux?
Si vous avez déjà un fichier ZIP pour commencer, cette réponse n'a aucun sens, car vous ne pouvez pas contrôler comment les utilisateurs vont créer leurs fichiers ZIP. Si vous décidez de "diviser le fichier d'origine en parties", vous devrez toujours extraire le fichier d'origine et seulement après cela, vous pourrez créer plusieurs fichiers zip partiels, ce qui est évidemment perte de temps.
Utilisez la bibliothèque DotNetzip, vous pouvez extraire tout le fichier simplement à l'aide d'Extractall () Méthode :)
Si la mise à niveau de votre projet sur .NET 4.5 est une option, vous pouvez utiliser le zipararchive classe. J'ai écrit un article sur l'utiliser, et c'est simple simple. Il y a aussi zipfile , quel J'ai également écrit sur et est même Plus facile. Je ne peux pas commenter la performance cependant, car je n'ai pas utilisé de bibliothèques tiers pour les archives zip.
Les liens de blog sont morts.
Faire nos propres tests, 7-ZIP CLI (fichier EXE) a été la plus rapide de loin. Cela semble fou qu'une application CLI surperformerait toutes ces dlls .NET, mais malheureusement, c'est le fait.
Pour être précis, j'ai testé SharpCompress, SharpziPlib, DotNetZip, la propre implémentation de celle-ci à l'aide de ZIPFILE et ZIPARCHIVE. Tous fonctionnaient environ 10-20 secondes pour notre fichier de test, mais le processus EXE de 7-zip était généralement terminé à 7 à 8 secondes.
Voici un code exemple, si vous décidez d'utiliser 7- Zip:
En ce qui concerne performance de mon application est fortement basé sur la manière dont les fichiers .zip sont extraits - si vous décrivez plus loin, nous pourrions avoir des suggestions sur la manière d'optimiser. Avez-vous essayé des niveaux «compression la plus rapide» dans DotNetZip? Si vous avez le contrôle du côté de la compression, vous pourrez peut-être utiliser des approches de compression moins générales plus rapides pour décompresser également, si vos données sont contraintes d'une manière ou d'une autre.
Dommage que je dois extraire des fichiers qui ont été compressés par un autre doux, je ne peux donc pas choisir des niveaux de compression inférieurs.
Dans ma demande, il est utilisé environ la moitié de temps passé par la méthode principale, est utilisé en extrayant des archives .zip, donc l'amélioration du temps d'extraction serait une excellente amélioration de la performance. Après avoir extraites, j'ai besoin d'accéder à certaines métadonnées sur les fichiers et, après cela, déplacez-les vers d'autres emplacements basés sur des métadonnées.
Votre méthode principale nécessite-t-elle / pourrait faire autre chose pendant que les fichiers zip sont extrants? Peut valoir la peine de déplacer l'extraction à un ouvrier de fond, du thread ou de l'appel d'ASYNC pour augmenter les performances s'il s'agit d'une option
La méthode d'extraction est déjà dans le travail d'arrière-plan, mais puisque l'application nécessite des données extraites pour effectuer la fonction suivante, j'ai toujours besoin d'attendre, tandis que les données sont extraites.
Vous pouvez extraire le premier 1kb pour lire l'en-tête, puis extraire directement à l'emplacement final. Cela devrait être beaucoup plus rapide aussi bien.