cs_max12
Messages postés1491Date d'inscriptiondimanche 19 novembre 2000StatutModérateurDernière intervention 7 juillet 2014
-
31 juil. 2007 à 23:10
ndubien
Messages postés557Date d'inscriptiondimanche 25 septembre 2005StatutMembreDernière intervention10 mai 2014
-
22 avril 2009 à 18:47
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
ndubien
Messages postés557Date d'inscriptiondimanche 25 septembre 2005StatutMembreDernière intervention10 mai 20144 22 avril 2009 à 18:47
Pour informations:
Il me semble que votre version WIN32 ne fonctionne pas avec Windows Vista : lorsque j'ai voulu compresser, windows m'a envoyer le message "ce programme ne répond plus" !
Malgré ce léger problème, cette source me semble être très intéressante pour comprendre le fonctionnement de cette méthode de compression !
Neo_Fr
Messages postés653Date d'inscriptionmardi 6 décembre 2005StatutMembreDernière intervention10 novembre 20142 2 août 2007 à 22:51
"...les 2 versions lise le fichier de le meme facon"
Les deux versions lisent bien le fichier octet par octet
Maintenant si tu me dit que les apis ne sont pas optimisé pour lire octet par octet ca repond a ma question
je trouve quand meme un peu surprenant que les apis fassent pires que les crt...
sinon pour les types c'est juste parceque je prefere :p
shenron666
Messages postés229Date d'inscriptiondimanche 14 septembre 2003StatutMembreDernière intervention20 août 2014 2 août 2007 à 20:01
au risque de me répéter, quelle est la ou quelles sont les différence(s) entre ton implémentation et l'implémentation originale ?
- types utilisés (tu utilises des defines ce qui revient au même)
- méthodes d'allocation / désallocation
- méthode de lecture écriture sur disque
si je n'ai rien oublié ça va vite à faire le tour
et ce que tu dis :
"...les 2 versions lise le fichier de le meme facon"
est faux, tu as changé les routines de lecture
reprends les routines utilisées à l'origine et testes par toi même
les routines Win32 que tu utilises sont des routines pour lire et écrire des blocs de données
elles ne sont pas optimisées pour lire et écrire octet par octet contrairement aux routines fputc et fgetc
pour ce qui est d'adapter pour la performance, c'est pas en changeant les types utilisés mais la façon de traiter les données
détermines la partie du programme qui s'avère être un goulot d'étranglement et améliore cette partie
comme le suggère f_l_a_s_h_b_a_c_k, fais en sorte que les routines de codage / décodage travaillent sur des blocs plutot que octet par octet
bon courage
Neo_Fr
Messages postés653Date d'inscriptionmardi 6 décembre 2005StatutMembreDernière intervention10 novembre 20142 2 août 2007 à 07:44
Oui d'accord pour ca, mais pourquoi la version avec les apis est + lente que la version originale alors que les 2 versions lise le fichier de le meme facon
f_l_a_s_h_b_a_c_k
Messages postés56Date d'inscriptionvendredi 14 avril 2006StatutMembreDernière intervention 1 février 2009 1 août 2007 à 23:31
pour la vitesse je ferais quelque chose comme ca,
il va compresser en memoire et lire et ecrire en une shot de 50000 le gain en vitesse!
se que je peur voir avec ton code il lit un bytes a la fois!
compress_file(char name[256])
{ char *mem;
char *memout;
FILE *fpin;
FILE *fpout;
long l=0;
long lo=0;
Neo_Fr
Messages postés653Date d'inscriptionmardi 6 décembre 2005StatutMembreDernière intervention10 novembre 20142 1 août 2007 à 22:39
Si j'ai essayer de l'adapter c'est pour la performance, pour les routines de lecture et d'écriture je ne vois pas pourquoi les apis serait plus lente elles sont censé etre plus rapide que les runtimes, je me suis surement planter quelque part mais ou??
shenron666
Messages postés229Date d'inscriptiondimanche 14 septembre 2003StatutMembreDernière intervention20 août 2014 1 août 2007 à 20:20
quel intérêt d'adapter un code portable en code non portable ?
pour ton problème de rapidité, tu peux regarder du côté des routines de lecture / écriture de fichiers
à part cela, et les routines d'allocation tu n'as pas changé grand chose donc faut pas chercher loin
Neo_Fr
Messages postés653Date d'inscriptionmardi 6 décembre 2005StatutMembreDernière intervention10 novembre 20142 31 juil. 2007 à 23:32
Mon pb c'est pa l'algo en lui meme, mon pb c'est que la version que j'ai adapter en win32 et + lente que l'originale et ca me parait vraiment bizarre.
cs_max12
Messages postés1491Date d'inscriptiondimanche 19 novembre 2000StatutModérateurDernière intervention 7 juillet 2014 31 juil. 2007 à 23:10
En faisant les statistiques permettant la compresison tu peux toujours sauter des caractère pour gagner un peu de speed. Ensuite je te dirais simplement de prendre un autre algorithme car Huffman c'est pourrit pour cette utilisation, au mieux sa peut servir a compresser du texte avec un arbre déjà fait et encore.
22 avril 2009 à 18:47
Il me semble que votre version WIN32 ne fonctionne pas avec Windows Vista : lorsque j'ai voulu compresser, windows m'a envoyer le message "ce programme ne répond plus" !
Malgré ce léger problème, cette source me semble être très intéressante pour comprendre le fonctionnement de cette méthode de compression !
2 août 2007 à 22:51
Les deux versions lisent bien le fichier octet par octet
Maintenant si tu me dit que les apis ne sont pas optimisé pour lire octet par octet ca repond a ma question
je trouve quand meme un peu surprenant que les apis fassent pires que les crt...
sinon pour les types c'est juste parceque je prefere :p
2 août 2007 à 20:01
- types utilisés (tu utilises des defines ce qui revient au même)
- méthodes d'allocation / désallocation
- méthode de lecture écriture sur disque
si je n'ai rien oublié ça va vite à faire le tour
et ce que tu dis :
"...les 2 versions lise le fichier de le meme facon"
est faux, tu as changé les routines de lecture
reprends les routines utilisées à l'origine et testes par toi même
les routines Win32 que tu utilises sont des routines pour lire et écrire des blocs de données
elles ne sont pas optimisées pour lire et écrire octet par octet contrairement aux routines fputc et fgetc
pour ce qui est d'adapter pour la performance, c'est pas en changeant les types utilisés mais la façon de traiter les données
détermines la partie du programme qui s'avère être un goulot d'étranglement et améliore cette partie
comme le suggère f_l_a_s_h_b_a_c_k, fais en sorte que les routines de codage / décodage travaillent sur des blocs plutot que octet par octet
bon courage
2 août 2007 à 07:44
1 août 2007 à 23:31
il va compresser en memoire et lire et ecrire en une shot de 50000 le gain en vitesse!
se que je peur voir avec ton code il lit un bytes a la fois!
compress_file(char name[256])
{ char *mem;
char *memout;
FILE *fpin;
FILE *fpout;
long l=0;
long lo=0;
mem=malloc(50 000);
memou=malloc(50 000);
fpin=fopen(name,rb);
fpou=fopen(name,rb);
do {
l=fread(mem,50 000,1,fpin);
huffman_encode_memory(mem, l, *memout, &lo);
l=fwrite(mem,lo,1,fpou);
} while(!feof(fp);
free(mem);
free(memou);
fclose(fpin);
fclose(fpou);
}
1 août 2007 à 22:39
1 août 2007 à 20:20
pour ton problème de rapidité, tu peux regarder du côté des routines de lecture / écriture de fichiers
à part cela, et les routines d'allocation tu n'as pas changé grand chose donc faut pas chercher loin
31 juil. 2007 à 23:32
31 juil. 2007 à 23:10