Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows XP Discussions Générales Compression d'un disque dur

Compression d'un disque dur

22 réponses
Avatar
Speed-2vil
Bonjour a tous,
je souhaite connaitre les avantages et inconvenients a=20
compresser un lecteur.
Comment se comporteront les nouveaux fichiers qui seront=20
stock=E9s sur ce disque compress=E9,quels sont sont les=20
risques pour ceux deja stock=E9s sur celui-ci etc...
Merci de vos reponses.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
kazimyr
Bonjour
Bon allez je vous ai lu , j'ai frémi mais j'ai testé pendant vos échanges
verbaux : sur mon pc de bureau en plus ce qui , avouez le , est un grand risque
car je ne sais pas revenir en arrière : la config étant un P2.4ghz , 512 ddram ,
disque dur 7200 trs : pas de différence de vitesse visible en bureautique ..ceci
dit c'est pas ici que je vais pouvoir tester un jeu , mon patron n'aimerait pas
mais j'ai des applics personnalisées très très gourmandes et ça ne changer rien
donc..... Ceci dit je ne suis pas un champion en informatique ...
Ce qui fait que , soit je vous renvoie dos à dos, soit j'abonde dans le sens de
JC mais j'ai rarement vu JC se planter .
Après tout c'est si important d'avoir raison à tout prix ?
:-)


Mais si tu lis le fichier compressé, ce qui reste à démontrer, il faut dans
ce cas compresser la rechercher pour la comparer au fichier, ce qui anile
l'action précédente...

--
Merci, @+, bye, Joe
troll75 AROBASE iFrance POINT com
------------------------------------------
Le_Troll, éleveur de Trolls depuis César, qui disait:
Avec une hache, celui qui tient le manche a toujours raison !


"Jean-Claude BELLAMY" a écrit dans le
message de news:

Dans le message news:uk$ ,
le_troll s'est ainsi exprimé:


Eh BELLAMY, déjà que tu m'as envoyé chier une fois que je te
demandais des renseignements pour cracker NT (d'après ton site),


Je ne suis pas un pirate et n'ai jamais encouragé le piratage ...
Si je t'ai envoyé "faciliter ton transit intestinal", c'est que j'ai eu
raison de le faire ...


n'oublies pas moi! Maintenant tu viens dire des conneries:
Un fichier compressé est illisible directement par l'OS,


çà ne veut rien dire "par l'OS" !
Un OS comporte forcément un gestionnaire de fichiers, qui supporte un ou
plusieurs système de fichiers, lesquels ont pour mission de décoder
éventuellement les fichiers compressés ou chiffrés.


il passe par
une décompression suivant un algorithme, puis in fine, repasse par
une phase de compression, ceci en plus des opération habituelles;


Qui a dit le contraire ?


alors que ce soit transparent (éventuellement), mais que ça ne prenne
pas plus de temps CPU,


Tu mérite bien ton pseudo de troller , toi !
Tu devrais concourir dans la catégorie "mauvaise foi" ...

A quel endroit ai-je dit que cela ne consommait pas de CPU ?

"[...]
En effet, si les opérations de compression/décompression
consomment du temps CPU,[...]"

Bien sûr que les opérations de compression/décompression consomment du


temps

CPU.

MAIS :
" en contrepartie, comme un fichier compressé occupe
(généralement) beaucoup moins d'espace sur le DD,
les temps de transferts (lecture et écriture) sont
considérablement réduits."

Donc le temps GLOBAL peut se voir réduit.


ben tu bave des conneries, retourne sur NT!


Au fait, je te signale que XP fait partie de la famille NT!
Donc je n'ai pas besoin d'y retourner, j'y suis déjà..


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *











Avatar
JacK [MVP]
sur les news:
Jean-Claude BELLAMY signalait:

Bien sûr que les opérations de compression/décompression consomment
du temps CPU.

MAIS :
" en contrepartie, comme un fichier compressé occupe
(généralement) beaucoup moins d'espace sur le DD,
les temps de transferts (lecture et écriture) sont
considérablement réduits."

Donc le temps GLOBAL peut se voir réduit.


Hello JCB,

Je ne suis pas ton raisonnement ? Puisqu'avant de lire et d'écrire, la
décompression doit avoir lieu.

Eventuellement, le déplacement du bras sera moindre si l'espace à parcourir
est plus petit mais je ne vois pas comment le temps global serait réduit.

J'ai *toujours* constaté des ralentissements, qu'il s'agisse d'un lecteur
compressé ou de dossiers ou fichiers après avoir compressé et testé sur le
même lecteur les deux possibilités avec différents benchmarks ATTO, PC Mark,
WinMark, Winstone, Sandra.

Cordialement,
--
http://www.optimix.be.tf /MVP WindowsXP/ http://websecurite.org
http://www.msmvps.com/XPditif/
http://experts.microsoft.fr/longhorn4u/
*Helping you void your warranty since 2000*
---***ANTISPAM***---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(*0*)@ JacK

Avatar
Jean-Claude BELLAMY
Dans le message news:% ,
JacK [MVP] s'est ainsi exprimé:

sur les news:
Jean-Claude BELLAMY signalait:

Bien sûr que les opérations de compression/décompression consomment
du temps CPU.

MAIS :
" en contrepartie, comme un fichier compressé occupe
(généralement) beaucoup moins d'espace sur le DD,
les temps de transferts (lecture et écriture) sont
considérablement réduits."

Donc le temps GLOBAL peut se voir réduit.


Hello JCB,

Je ne suis pas ton raisonnement ? Puisqu'avant de lire et d'écrire,
la décompression doit avoir lieu.

Eventuellement, le déplacement du bras sera moindre si l'espace à
parcourir est plus petit mais je ne vois pas comment le temps global
serait réduit.


????????????????????????????????
Çà me semble pourtant ÉVIDENT !

Le temps nécessaire pour lire ou écrire un fichier sur disque est
proportionnel à la taille de ce fichier!
(en faisant abstraction des temps fixes dus au positionnement des têtes et
autres routines d'initialisation)

SI il y a un cache disque important, et SI on vient lire ou écrire une 2ème
fois un ficher dans la même zone, certes le gain (ou la perte, suivant le
cas) de temps sera atténué pour cette 2ème opération.


J'ai *toujours* constaté des ralentissements, qu'il s'agisse d'un
lecteur compressé ou de dossiers ou fichiers après avoir compressé et
testé sur le même lecteur les deux possibilités avec différents
benchmarks ATTO, PC Mark, WinMark, Winstone, Sandra.
Pas convaincu (j'ai une partition avec plein de fichers compressés, je n'ai

remarqué AUCUN ralentissement, au contraire)
En ce qui concerne les tests que tu cites, il faudrait connaitre le détail
exact du protocole de mesure utilisé. (en particulier quels moments sont
considérés comme début et fin de lecture ou d'écriture)


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *



Avatar
Jean-Claude BELLAMY
Dans le message news: ,
le_troll s'est ainsi exprimé:

Mais si tu lis le fichier compressé, ce qui reste à démontrer, il
faut dans ce cas compresser la rechercher pour la comparer au
fichier, ce qui anile l'action précédente...


Et en français, qu'est-ce que çà donne ? ;-)
"compresser la rechercher " ????

Et que vient faire cette histoire de comparaison ?
Et quelle action va être annihilée ?
(du latin "ad" = vers, et "nihil" = rien - ;-))


Si une appli demande à lire un fichier, le gestionnaire de fichiers est
alors sollicité.
En particulier, les attributs du fichiers sont lus.
Si la partition est de type NTFS, et si l'attribut "compressé" est
positionné, la routine de décompression (LZread) va être appelée, et le
résultat transmis à l'application initiale.


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *


Avatar
JacK [MVP]
sur les news:%
Jean-Claude BELLAMY signalait:
Dans le message news:% ,
JacK [MVP] s'est ainsi exprimé:

Hello JCB,

Je ne suis pas ton raisonnement ? Puisqu'avant de lire et d'écrire,
la décompression doit avoir lieu.

Eventuellement, le déplacement du bras sera moindre si l'espace à
parcourir est plus petit mais je ne vois pas comment le temps global
serait réduit.


????????????????????????????????
Çà me semble pourtant ÉVIDENT !

Le temps nécessaire pour lire ou écrire un fichier sur disque est
proportionnel à la taille de ce fichier!
(en faisant abstraction des temps fixes dus au positionnement des
têtes et autres routines d'initialisation)


Bien sûr mais comme ce fichier est décompressé avant d'écrire ou lire, il
fait très exactement la même taille que s'il ne l'était pas à ce moment-là,
non ?

J'ai *toujours* constaté des ralentissements, qu'il s'agisse d'un
lecteur compressé ou de dossiers ou fichiers après avoir compressé et
testé sur le même lecteur les deux possibilités avec différents
benchmarks ATTO, PC Mark, WinMark, Winstone, Sandra.


Pas convaincu (j'ai une partition avec plein de fichers compressés,
je n'ai remarqué AUCUN ralentissement, au contraire)
En ce qui concerne les tests que tu cites, il faudrait connaitre le
détail exact du protocole de mesure utilisé. (en particulier quels
moments sont considérés comme début et fin de lecture ou d'écriture)


Tu peux consulter le protocole de ces tests sans aucune difficulté chez
leurs éditeurs respectifs, se sont les tests standards qui sont utilisés
pour faire des benchmarks et comparer les performances des disques du
marché. Ils sont tous très connus. La différence de résultats entre ces
différents benchmarks tient justement au fait qu'ils ont des protocoles
différents et ne testent pas la même chose. Certains testent les perf
graphiques, d'autres les perf brutes, d'autres des logiciels bureautiques,
etc...
Faire les différents tests après un fresh reboot sur un même lecteur
compressé ou non donnent pour *tous* les tests un avantage aux volumes non
compressés NTFS, quelle que soit la taille du lecteur concerné,
particulièrment sur de petites config.

Perso, je compresse les fichiers dont je ne me sers que rarement.
--
http://www.optimix.be.tf /MVP WindowsXP/ http://websecurite.org
http://www.msmvps.com/XPditif/
http://experts.microsoft.fr/longhorn4u/
*Helping you void your warranty since 2000*
---***ANTISPAM***---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(*0*)@ JacK


Avatar
Jean-Claude BELLAMY
Dans le message news: ,
JacK [MVP] s'est ainsi exprimé:

sur les news:%
Jean-Claude BELLAMY signalait:
[...]
Le temps nécessaire pour lire ou écrire un fichier sur disque est
proportionnel à la taille de ce fichier!
(en faisant abstraction des temps fixes dus au positionnement des
têtes et autres routines d'initialisation)


Bien sûr mais comme ce fichier est décompressé avant d'écrire ou
lire, il fait très exactement la même taille que s'il ne l'était pas
à ce moment-là, non ?


Re-???????????? ;-)
En mémoire, oui, mais pas sur le disque !

Sur le disque, physiquement, c'est bien sous forme compressée qu'il réside!
Donc ce sont bien les données COMPRESSÉES qui sont lues ou écrites !
Donc le temps de lecture ou d'écriture est bien réduit par rapport à celui
qu'on observerait dans le cas de fichier décompressé !


[...]
Perso, je compresse les fichiers dont je ne me sers que rarement.
Idem pour moi d'ailleurs ....



--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *



Avatar
Dorian
JacK [MVP] wrote:

Bien sûr mais comme ce fichier est décompressé avant d'écrire ou
lire, il fait très exactement la même taille que s'il ne l'était pas
à ce moment-là, non ?


Oui mais il est décompressé en mémoire, qui elle est beaucoup plus rapide.

Faire les différents tests après un fresh reboot sur un même lecteur
compressé ou non donnent pour *tous* les tests un avantage aux
volumes non compressés NTFS, quelle que soit la taille du lecteur
concerné, particulièrment sur de petites config.


Je ne sais pas comment la compression influe sur les performances générales
du système (et cela dépend du cpu et surtout de la quantité de RAM) , mais
ca améliore grandement la vitesse de manipulation de fichiers. Pour s'en
convaincre c'est très simple, il suffit de comparer le temps qu'il faut pour
copier un fichier dans les deux cas, non compressé et compressé ( cas
extrème: un fichier volumineux remplis de 0 ). La seconde utilité pratique
qui en découle, c'est une défragmentation plus rapide.

Aussi, pour avoir tester si un compresseur d'éxécutable (comme upx) influe
sur le temps de chargement d'une application, et bien je pous veux dire
qu'une application compressée se charge plus vite.

--
http://cerbermail.com/?yk4ys4MRJK

Avatar
Sebastien Vienot [MS]
Bonsoir,

Je confirme ce que dit JC, compresser un disque dur peut améliorer les
performances d'un ordi (en ce qui concerne les performances disques), et
c'est clairement le cas sur des portables (là où le disque dur est lent).

En effet, en ayant compressés les fichiers, il y aura moins de temps passé à
lire/écrire sur le disque. Il est vrai qu'il faut passer du temps à
compresser/décompresser ce qui est lu ou écrit, mais ce temps reste cumulé
(lire/écrire + décompresser/compresser) reste inférieur au temps de
lecture/écriture du même fichier non compressé.

Ceci est d'autant plus visible si le disque dur est lent, si le nombre
d'accès disque est important (beaucoup de manipulations de fichiers), et que
les fichiers sont compressibles (c'est à dire, pas de jpeg, pas de divx
...).

Ceci est par contre faux dans le cas de machines de type serveurs, qui
possèdent généralement des disques SCSI beaucoup plus rapides, avec des
configs de type RAID qui partage les IOs sur plusieurs disques (RAID 0 par
exemple), et qui embarque aussi très souvent du cache sur leur contrôleur.

Mais pour des portables, ça vaut généralement le coup.

Seb

"Jean-Claude BELLAMY" wrote in message
news:O8kPf%
Dans le message news: ,
le_troll s'est ainsi exprimé:

Mais si tu lis le fichier compressé, ce qui reste à démontrer, il
faut dans ce cas compresser la rechercher pour la comparer au
fichier, ce qui anile l'action précédente...


Et en français, qu'est-ce que çà donne ? ;-)
"compresser la rechercher " ????

Et que vient faire cette histoire de comparaison ?
Et quelle action va être annihilée ?
(du latin "ad" = vers, et "nihil" = rien - ;-))


Si une appli demande à lire un fichier, le gestionnaire de fichiers est
alors sollicité.
En particulier, les attributs du fichiers sont lus.
Si la partition est de type NTFS, et si l'attribut "compressé" est
positionné, la routine de décompression (LZread) va être appelée, et le
résultat transmis à l'application initiale.


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org *






Avatar
JMM
Bonsoir

j'ai testé pour voir quel pouvait être le gain en place sur un DD
ce gain est réellement significatif
partition de 57.2 Giga (61 467 484 160 oct)
utilisée 43.5 giga ( 46 751 760 384 o)
libre 13.7 giga (14 715 723 776 o)

après compression
utilisée 35.3 giga (37 949 845 504 o)
libre 21.9 giga (23 517 638 656 o)

soit un espace libérer de 8.2 giga (8 803 958 784 o) soit un gain de 14.34%

sur cette partition (sauvegarde) il y a de tout (documents, données, photos,
musique.......)


--
====================== cordiales salutations
JMM
======================
"Dorian" a écrit dans le message de news:

JacK [MVP] wrote:

Bien sûr mais comme ce fichier est décompressé avant d'écrire ou
lire, il fait très exactement la même taille que s'il ne l'était pas
à ce moment-là, non ?


Oui mais il est décompressé en mémoire, qui elle est beaucoup plus rapide.

Faire les différents tests après un fresh reboot sur un même lecteur
compressé ou non donnent pour *tous* les tests un avantage aux
volumes non compressés NTFS, quelle que soit la taille du lecteur
concerné, particulièrment sur de petites config.


Je ne sais pas comment la compression influe sur les performances
générales

du système (et cela dépend du cpu et surtout de la quantité de RAM) , mais
ca améliore grandement la vitesse de manipulation de fichiers. Pour s'en
convaincre c'est très simple, il suffit de comparer le temps qu'il faut
pour

copier un fichier dans les deux cas, non compressé et compressé ( cas
extrème: un fichier volumineux remplis de 0 ). La seconde utilité pratique
qui en découle, c'est une défragmentation plus rapide.

Aussi, pour avoir tester si un compresseur d'éxécutable (comme upx) influe
sur le temps de chargement d'une application, et bien je pous veux dire
qu'une application compressée se charge plus vite.

--
http://cerbermail.com/?yk4ys4MRJK




Avatar
JacK [MVP]
sur les news:O9Q%
JMM <JURASHIEN> signalait:
Bonsoir

j'ai testé pour voir quel pouvait être le gain en place sur un DD
ce gain est réellement significatif
partition de 57.2 Giga (61 467 484 160 oct)
utilisée 43.5 giga ( 46 751 760 384 o)
libre 13.7 giga (14 715 723 776 o)

après compression
utilisée 35.3 giga (37 949 845 504 o)
libre 21.9 giga (23 517 638 656 o)

soit un espace libérer de 8.2 giga (8 803 958 784 o) soit un gain de
14.34%

sur cette partition (sauvegarde) il y a de tout (documents, données,
photos, musique.......)

Hello,


Le gain es très variable selon le type de fichiers. Intéressant sur une
partition de sauvegarde puisque tu ne t'en sers pratiquement jamais.
--
http://www.optimix.be.tf /MVP WindowsXP/ http://websecurite.org
http://www.msmvps.com/XPditif/
http://experts.microsoft.fr/longhorn4u/
*Helping you void your warranty since 2000*
---***ANTISPAM***---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(*0*)@ JacK

1 2 3