Yep, je suis d’accord, Python est une outre bourrée remorquée par un escargot1. Mais quand tu fais du Python, la vitesse d’ouverture d’un fichier est le dernier de tes soucis question performance. Dans le cas contraire, il y a un sérieux problème dans un programme qui veut ouvrir un fichier toutes les 10 ms. Je voulais juste remettre en doute l’affirmation qui dit que les chaînes de caractères sont moins performantes que les flags. Dans l’absolu je ne le crois pas. Ce servir d’un langage lent pour dire que les chaînes de caractères dans fopen sont longue à "parser", c’est « juste pas très honnête » :p
Par définition, la plus petite quantité de données adressable c'est le byte donc 8bits sur nos machines actuelles.
Mais es-tu certain, par exemple si je fais :
chara,b,c;a=54;b=18;c=a&b;
qu’un processeur 32 ou 64 bits va manipuler de bout en bout des octets et pas plutôt des entités de 4 ou 8 octets en interne (avec le "zero-padding" qui va bien).
Typiquement, pour des raisons de performances tu sais que :
struct{chara;intb;};
aura tendance à laisser un "trou" entre a et b, parce que « l’octet c’est bien gentil, mais les ordinateurs ont évolué depuis, et c’est pas forcément pertinent de redescendre à ce niveau là à l’heure actuelle ».
De même au niveau du processeur je me demande si, quand on lui demande une opération sur un octet, il ne se contente pas simplement d’appliquer un masque sur une opération qu’il aura faite préalablement en 32 ou 64 bits.
Enfin l'utilisation de constantes fait que tu n'a pas à parser l'argument tu t'en sert directement comme d'un tableau de booléens.
?!?
Je ne sais pas trop ce que tu as voulu dire. Typiquement, pour le C ce que je fais dans ce cas là c’est de tester mon argument qui contient les flags, appelons le arg, avec des flagsA, B, C, etc. pour cela je fais le test :
arg&A;/* renvoie un nombre différent de 0, ou 0, pour savoir si le flag a été allumé, ou pas, respectivement. */
C’est une opération bit-à-bit et un test par flag, si tu as 8 flag ça tient dans un octet. Partant de là, le fopen du C ne doit pas être moins performant que son équivalent avec flag : 6 modes possibles, 6 tests d’égalité à faire, sur un octet. Effectivement si tu t’amuses à ne plus définir l’ordre des caractères, ou à augmenter la taille de la chaîne, alors je veux bien croire qu’il vaut mieux utiliser des flags.
1 J’utilise ce langage tous les jours et je l’adore. Même si ça ne se voit pas.
PS : j’en profite de t’avoir sous la main pour un commentaire sur markdown. tralala_: poum, où « _ » est une espace insécable, perturbe l’analyse de *lala* pour le mettre en italique. Comme *ici* : snif.
[^] # Re: Les vrais ajouts
Posté par BB . En réponse au journal Java 7 est dispo !. Évalué à 2.
Yep, je suis d’accord, Python est une outre bourrée remorquée par un escargot1. Mais quand tu fais du Python, la vitesse d’ouverture d’un fichier est le dernier de tes soucis question performance. Dans le cas contraire, il y a un sérieux problème dans un programme qui veut ouvrir un fichier toutes les 10 ms. Je voulais juste remettre en doute l’affirmation qui dit que les chaînes de caractères sont moins performantes que les flags. Dans l’absolu je ne le crois pas. Ce servir d’un langage lent pour dire que les chaînes de caractères dans fopen sont longue à "parser", c’est « juste pas très honnête » :p
Mais es-tu certain, par exemple si je fais :
qu’un processeur 32 ou 64 bits va manipuler de bout en bout des octets et pas plutôt des entités de 4 ou 8 octets en interne (avec le "zero-padding" qui va bien).
Typiquement, pour des raisons de performances tu sais que :
aura tendance à laisser un "trou" entre a et b, parce que « l’octet c’est bien gentil, mais les ordinateurs ont évolué depuis, et c’est pas forcément pertinent de redescendre à ce niveau là à l’heure actuelle ».
De même au niveau du processeur je me demande si, quand on lui demande une opération sur un octet, il ne se contente pas simplement d’appliquer un masque sur une opération qu’il aura faite préalablement en 32 ou 64 bits.
?!?
Je ne sais pas trop ce que tu as voulu dire. Typiquement, pour le C ce que je fais dans ce cas là c’est de tester mon argument qui contient les flags, appelons le
arg, avec des flagsA,B,C, etc. pour cela je fais le test :C’est une opération bit-à-bit et un test par flag, si tu as 8 flag ça tient dans un octet. Partant de là, le fopen du C ne doit pas être moins performant que son équivalent avec flag : 6 modes possibles, 6 tests d’égalité à faire, sur un octet. Effectivement si tu t’amuses à ne plus définir l’ordre des caractères, ou à augmenter la taille de la chaîne, alors je veux bien croire qu’il vaut mieux utiliser des flags.
1 J’utilise ce langage tous les jours et je l’adore. Même si ça ne se voit pas.
PS : j’en profite de t’avoir sous la main pour un commentaire sur markdown. tralala_: poum, où « _ » est une espace insécable, perturbe l’analyse de
*lala*pour le mettre en italique. Comme *ici* : snif.