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.
Salut, -1- Mais c'est normal, dans la cas d'une copie, il n'a pas besoin de décompresser si c'est une copie compressée... -2- Sur ce qui a été dit sur la lecture/écriture, parlant de bras, le disque est lu en cylindres conrairement à la disquette (qui est lue en piste puis secteurs). -3- Un opération sur un fichier (telle que recherche/comparaison), n'est jamais faite sur le disque, il faut passer par la mémoire...
-- 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 !
"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
Salut,
-1- Mais c'est normal, dans la cas d'une copie, il n'a pas besoin de
décompresser si c'est une copie compressée...
-2- Sur ce qui a été dit sur la lecture/écriture, parlant de bras, le disque
est lu en cylindres conrairement à la disquette (qui est lue en piste puis
secteurs).
-3- Un opération sur un fichier (telle que recherche/comparaison), n'est
jamais faite sur le disque, il faut passer par la mémoire...
--
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 !
"Dorian" <Dorian.B@nospam.invalid> a écrit dans le message de news:
eUR6YVsiEHA.2068@TK2MSFTNGP15.phx.gbl...
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.
Salut, -1- Mais c'est normal, dans la cas d'une copie, il n'a pas besoin de décompresser si c'est une copie compressée... -2- Sur ce qui a été dit sur la lecture/écriture, parlant de bras, le disque est lu en cylindres conrairement à la disquette (qui est lue en piste puis secteurs). -3- Un opération sur un fichier (telle que recherche/comparaison), n'est jamais faite sur le disque, il faut passer par la mémoire...
-- 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 !
"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
le_troll
Salut, -1- Mais c'est normal, dans la cas d'une copie, il n'a pas besoin de décompresser si c'est une copie compressée... -2- Sur ce qui a été dit sur la lecture/écriture, parlant de bras, le disque est lu en cylindres contrairement à la disquette (qui est lue en piste puis secteurs). -3- Un opération sur un fichier (telle que recherche/comparaison), n'est jamais faite sur le disque, il faut passer par la mémoire...
-- 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 !
"JacK [MVP]" a écrit dans le message de news: #
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
Salut,
-1- Mais c'est normal, dans la cas d'une copie, il n'a pas besoin de
décompresser si c'est une copie compressée...
-2- Sur ce qui a été dit sur la lecture/écriture, parlant de bras, le disque
est lu en cylindres contrairement à la disquette (qui est lue en piste puis
secteurs).
-3- Un opération sur un fichier (telle que recherche/comparaison), n'est
jamais faite sur le disque, il faut passer par la mémoire...
--
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 !
"JacK [MVP]" <ihate@spam.gov> a écrit dans le message de news:
#Hs7PpqiEHA.3988@tk2msftngp13.phx.gbl...
sur les news:OKTbIdpiEHA.1376@TK2MSFTNGP11.phx.gbl
Jean-Claude BELLAMY <Jean-Claude.Bellamy@wanadoo.fr> 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
Salut, -1- Mais c'est normal, dans la cas d'une copie, il n'a pas besoin de décompresser si c'est une copie compressée... -2- Sur ce qui a été dit sur la lecture/écriture, parlant de bras, le disque est lu en cylindres contrairement à la disquette (qui est lue en piste puis secteurs). -3- Un opération sur un fichier (telle que recherche/comparaison), n'est jamais faite sur le disque, il faut passer par la mémoire...
-- 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 !
"JacK [MVP]" a écrit dans le message de news: #
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
