Fichiers non-ordonnés sous Windows

[quote][quote]B’soir

[…]

une soluce???[/quote]Euh, fermer l’explorateur ?

En
fait, comme tu dis au moment d’ouvrir un répertoire, Windows XP va
utiliser l’ordre que tu lui donnes. Par contre, ensuite, il va combler
les trous, puis rajouter les fichiers un à un, au fur et à mesure qu’il
les crée en fait. Un exemple : Place-toi dans un répertoire et déplace
n’importe quel fichier. Puis fait Annuler (CTRL + Z). Hop le fichier va
se placer à la fin (c’est d’ailleurs ce qu’il fait par défaut) !
Cela est tout simplement une optimisation de l’Explorer pour éviter
qu’il se retape un tri à chaque fois que quelque chose est modifié dans
un répertoire. Autrement dit, c’est une feature d’Explorer (sinon, il serait BEAUCOUP plus lent) et on n’y peut pas grand chose…
Ce message a été édité par xentyr le 02/06/2003[/quote]
“Optimisation” ??
Attends, dans le pire des cas, si les fichiers sont stockés dans une liste, et supposons que le répertoire en cours contienne 10000 fichiers, eh bien, toujours dans le pire des cas, il faudra une boucle de 10000 itérations pour insérer le fichier au bon endroit. Bref, l’affaire d’un dixième de seconde…

Ce message a été édité par xentyr le 06/06/2003

[quote][quote]
“Optimisation”
?? Attends, dans le pire des cas, si les fichiers sont stockés dans une
liste, et supposons que le répertoire en cours contienne 10000
fichiers, eh bien, toujours dans le pire des cas, il faudra une boucle
de 10000 itérations pour insérer le fichier au bon endroit. Bref,
l’affaire d’un dixième de seconde…[/quote]Un dixième de seconde par
ci, un dixième de seconde par là quand tu copies/colles plusieurs
fichiers à la fois, et que tu annules, que tu renommes, au final, ça
devient non négligeable, hein. C’est ça que j’appelle
optimisation. L’ordre du dixième de seconde, c’est… ÉNORME
en informatique, car c’est perceptible. Donc si on peut gagner sur
quelque chose d’aussi anodin qu’un tri, on le fait (en tout cas JE l’ai
fait dans un projet Explorer-like alors que j’avais déjà programmé la feature :
hop on bazarde, on optimise). L’utilisateur qui veut trier TOUT LE
TEMPS est plus rare et donc celui-ci devra cliquer sur la colonne…

Ce message a été édité par xentyr le 06/06/2003[/quote]
Dans ce cas suffit d’adopter une structure aborescente pour le stockage (type avl ou arbre rouge-noir). Ca fera faire 10-11 tests pour trouver la bonne position d’un fichier. Lorsque 10 fichiers sont copier-collé, il devrait y avoir moyen de faire toutes les recherches en même temps.

Je suis d’accord quand tu dis qu’un dixième de seconde c’est lent, mais j’ai quand même pris le pire des cas…

Après faut voir si niveau pratique, c’est bien ou pas (avoir les fichiers copier-collé immédiatement trié dans un rep de 10000 fichiers est peut-être pas forcément idél), mais l’argument avancé en premier n’était pas celui-là.

Moi je VEUX avoir les nouveaux fichiers qui se collent a la fin. Je supporte pas de coller qqch et de presser F5 sans reflechir et de tous les perdre dans le desordre au milieu de ma liste alphabetique…

Sinon, sans consideration de ce qu’il vaut mieux faire. Niveau perfs c’est facile de dire :
 

  • “on va aller super vite si on fait X, Y ou Z” …
  • “ha ouai mais tu viens de bouffer X^12 megs de memoire vive pour te permettre d’aller vite avec ton super arbre/bidulle/index et puis quand ca swappe ca va ramer deux fois pire”.
  • “Ha … shit alors…”.
  • “Bon ben on va economiser de la memoire… faire un truc leger…”.
  • “ha merde… ca rame a mort”.
  • “Bon ben on trie qu’a la demande alors?”
  • “ouai ok on va faire ca.”

Vitesse ou memoire il faut choisir. Si tu veux aucun des deux, tu as deux choix:

  • t’as la lumiere divinne et tu trouve un truc super malin (1 cas sur 1000)
  • tu supprimes la feature
    Ce message a été édité par GloP le 07/06/2003

[quote]Dans ce cas suffit d’adopter une structure aborescente pour le stockage (type avl ou arbre rouge-noir). Ca fera faire 10-11 tests pour trouver la bonne position d’un fichier. Lorsque 10 fichiers sont copier-collé, il devrait y avoir moyen de faire toutes les recherches en même temps.
Je suis d’accord quand tu dis qu’un dixième de seconde c’est lent, mais j’ai quand même pris le pire des cas…[/quote]Effectivement, avec une structure d’arbre, on pourrait le faire. Mais c’est se faire chier pour pas grand chose, non ? En plus, avec ton arbre, on attaque un autre problème. Comment tu l’équilibres facilement ? Je vous rappelle qu’on (enfin vous /wink.gif"> (rapport coût/développement/intérêt, tout ça, tout ça)
 

[quote]Après faut voir si niveau pratique, c’est bien ou pas (avoir les fichiers copier-collé immédiatement trié dans un rep de 10000 fichiers est peut-être pas forcément idél), mais l’argument avancé en premier n’était pas celui-là.[/quote]Bon ben j’aurais dû tout dire en fait. Mea Culpa. À force de vouloir tout raccourcir hum-hum. Oui, c’est aussi pour ça que j’ai retiré la feature. Après avoir vu certains users qui me gueulaient dessus : “Où sont passés les fichiers que j’ai copiés ? c’est nul ton truc !” . Donc ça, plus le fait que je suis resté en liste => hop poubelle.

Edit : Rhaaa GloP plus rapide que moi.

Ce message a été édité par xentyr le 07/06/2003

Tibo> lorsque des fichiers sont ajoutés au répertoire, tu fais un petit refresh (F5 comme sous IE) et hop, il réactualise le classement en fonction de la contrainte de tri que tu lui as donné, bien sûr.

Xentyr> Mouaif l’optimisation. Bon soit. De toutes façons, je ne trouve pas ça trop chiant de raffraichir “à la main” après une copie, par exemple. Cela dit, un OS aussi avancé qu’XP

[quote]Moi je VEUX avoir les nouveaux fichiers qui se collent a la fin. Je supporte pas de coller qqch et de presser F5 sans reflechir et de tous les perdre dans le desordre au milieu de ma liste alphabetique…[/quote]Oui, c’est vrai. En réfléchissant un peu, je VEUX aussi que mes fichiers restent là. TU RESTES LA !

Pour ceux qui veulent un autre fonctionnement, ça serait super d’avoir ce paramètre à disposition.

Et sur un PII 400 avec 32 megs ca donne quoi?
Ce message a été édité par GloP le 07/06/2003

Moktar a dit: Je viens de faire un petit essai de temps CPU pour un bout de code qui tourne 10000 fois. Les résultats sont évidents :

real   0m0.031s // user   0m0.030s // sys 0m0.010s

Si je refais le même essai avec un printf à chaque tour de boucle j’obtiens les résultats suivant :
real   0m0.415s // user   0m0.020s // sys 0m0.010s

Mouaif pas si terrible que ça hein

[quote]Et sur un PII 400 avec 32 megs ca donne quoi?
Ce message a été édité par GloP le 07/06/2003[/quote]Hahaha y’a pas XP sur un PII 400

[quote]

Moktar a dit: Je viens de faire un petit essai de temps CPU pour un bout de code qui tourne 10000 fois. Les résultats sont évidents :

real   0m0.031s // user   0m0.030s // sys 0m0.010s

Si je refais le même essai avec un printf à chaque tour de boucle j’obtiens les résultats suivant :
real   0m0.415s // user   0m0.020s // sys 0m0.010s

Mouaif pas si terrible que ça hein
Non je ne me suis même pas fait chier à trier, c’était juste pour donner un ordre d’idée . C’est vrai, j’aurais pu faire un p’tit tri à bulles mais les résultats auraient été du même ordre de grandeur.

[quote][quote]Et sur un PII 400 avec 32 megs ca donne quoi?
Ce message a été édité par GloP le 07/06/2003[/quote]Hahaha y’a pas XP sur un PII 400 [/quote]Bien sur que si. J’en ai un juste a cote de ma jambe droite. Et c’est utilisable a defaut d’etre confortable.
Ce message a été édité par GloP le 07/06/2003

[quote][quote]

[quote]Et sur un PII 400 avec 32 megs ca donne quoi?
Ce message a été édité par GloP le 07/06/2003[/quote]Hahaha y’a pas XP sur un PII 400 [/quote]Bien sur que si. J’en ai un juste a cote de ma jambe droite. Et c’est utilisable a defaut d’etre confortable.
Ce message a été édité par GloP le 07/06/2003[/quote]Avec du swap à tire larigot et même comme ça, ça doit être galère. M’enfin je veux bien te croire.

Si je regarde ce que je consomme en ce moment :
Total : 168676 octets (avec un pic à 192000)
Total pour le noyau : 69332

Mmhhhh… tu fais comment Gloppy ?

[quote]Avec du swap à tire larigot et même comme ça, ça doit être galère. M’enfin je veux bien te croire. Si je regarde ce que je consomme en ce moment : Total : 168676 octets (avec un pic à 192000) Total pour le noyau : 69332 Mmhhhh… tu fais comment Gloppy ?[/quote]C’est bien pour ca que j’aurais pas du tout les meme timing que toi si on refait ton experience sur un systeme sature comme ca.

Hihi ça serait rigolo. Je me souviens d’avoir été super impressionné de la vitesse à laquelle un 80286 pouvait rechercher un nombre dans un tableau de 256 entrées, lorsque je débutais

[quote]Hahahaha je veux des chiffres !
Non je ne me suis même pas fait chier à trier, c’était juste pour donner un ordre d’idée . C’est vrai, j’aurais pu faire un p’tit tri à bulles mais les résultats auraient été du même ordre de grandeur.[/quote]Je ne m’en rappelle plus exactement, mais je t’ai déjà donné l’ordre de grandeur : 0.1 s

Ensuite il s’agit d’une insertion d’une liste non triée (oui, on ne sait pas comment est triée la première liste) dans une autre déjà triée (ouf).

Enfin le bubble sort, c’est du gros caca. Quicksort vaincra ! Vive le O(n.log(n)) !!!

Ce message a été édité par xentyr le 07/06/2003

Oui tu as raison, le bubble sort c’est caca

La preuve par A + B : ici