Bonjour,
Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?
Merci de m'informer.
Bonjour,
Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?
Merci de m'informer.
Bonjour,
Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?
Merci de m'informer.
Bonjour,
Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?
Merci de m'informer.
Bonjour,
Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?
Merci de m'informer.
Bonjour,
Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?
Merci de m'informer.
"Barsalou" wrote in message
news:%23$Bonjour,
Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?
Merci de m'informer.
hello,
je n'ai pas la version initiation sous la main mais je
pense qu'elle dispose des mêmes options à savoir:
Quand tu génères ton exe:
"FileMake"
Tu as un bouton "Options"
Tu cliques dessus et tu as une form avec 2 onglets:
Le second onglet ("compile") te propose des options
d'optimisation:
Par défaut, il est sur "Optimize for Fast Code".
Tu as encore d'autre réglages dans "Advanced Optimisations"
qui permettent de générer du code plus rapide:
"désactiver le controle de bornes", "Désactiver le
controle d'overflow", etc.
--- MAIS ---
=> On ne gagne JAMAIS rien à essayer d'accélérer les choses
par des otpimisations de compilation.
=> La seule façon raisonnable d'augmenter les perfs (si
besoin est) est de choisir de meilleurs algorithmes, de
meilleures structures de données, ou d'utiliser des
fonctions bas niveau du système.
Exemple bête: si tu tries des nombres avec un tri à bulle,
il est inutile et ridicule de vouloir l'optimiser. Ca sera
toujours de toute façon hyper lent comparé à un meilleur
algorithme (par exemple un quick sort).
Autre exemple: Faire une recherche linéaire dans
un grand tableau de données sera toujours plus lent
que de faire une recherche dichotomique ou avec une hash
table.
Dans tous les cas, l'amélioration des perfs passe par de
meilleures structures/meilleurs algos/meilleures fonctions.
Donc pour répondre à ta question: ce type d'optimisation
par compilation est totalement inutile.
"Barsalou" <ericMettreUnPointbarsalou@wanadoo.fr> wrote in message
news:%23$CjAi6aHHA.4832@TK2MSFTNGP02.phx.gbl...
Bonjour,
Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?
Merci de m'informer.
hello,
je n'ai pas la version initiation sous la main mais je
pense qu'elle dispose des mêmes options à savoir:
Quand tu génères ton exe:
"FileMake"
Tu as un bouton "Options"
Tu cliques dessus et tu as une form avec 2 onglets:
Le second onglet ("compile") te propose des options
d'optimisation:
Par défaut, il est sur "Optimize for Fast Code".
Tu as encore d'autre réglages dans "Advanced Optimisations"
qui permettent de générer du code plus rapide:
"désactiver le controle de bornes", "Désactiver le
controle d'overflow", etc.
--- MAIS ---
=> On ne gagne JAMAIS rien à essayer d'accélérer les choses
par des otpimisations de compilation.
=> La seule façon raisonnable d'augmenter les perfs (si
besoin est) est de choisir de meilleurs algorithmes, de
meilleures structures de données, ou d'utiliser des
fonctions bas niveau du système.
Exemple bête: si tu tries des nombres avec un tri à bulle,
il est inutile et ridicule de vouloir l'optimiser. Ca sera
toujours de toute façon hyper lent comparé à un meilleur
algorithme (par exemple un quick sort).
Autre exemple: Faire une recherche linéaire dans
un grand tableau de données sera toujours plus lent
que de faire une recherche dichotomique ou avec une hash
table.
Dans tous les cas, l'amélioration des perfs passe par de
meilleures structures/meilleurs algos/meilleures fonctions.
Donc pour répondre à ta question: ce type d'optimisation
par compilation est totalement inutile.
"Barsalou" wrote in message
news:%23$Bonjour,
Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?
Merci de m'informer.
hello,
je n'ai pas la version initiation sous la main mais je
pense qu'elle dispose des mêmes options à savoir:
Quand tu génères ton exe:
"FileMake"
Tu as un bouton "Options"
Tu cliques dessus et tu as une form avec 2 onglets:
Le second onglet ("compile") te propose des options
d'optimisation:
Par défaut, il est sur "Optimize for Fast Code".
Tu as encore d'autre réglages dans "Advanced Optimisations"
qui permettent de générer du code plus rapide:
"désactiver le controle de bornes", "Désactiver le
controle d'overflow", etc.
--- MAIS ---
=> On ne gagne JAMAIS rien à essayer d'accélérer les choses
par des otpimisations de compilation.
=> La seule façon raisonnable d'augmenter les perfs (si
besoin est) est de choisir de meilleurs algorithmes, de
meilleures structures de données, ou d'utiliser des
fonctions bas niveau du système.
Exemple bête: si tu tries des nombres avec un tri à bulle,
il est inutile et ridicule de vouloir l'optimiser. Ca sera
toujours de toute façon hyper lent comparé à un meilleur
algorithme (par exemple un quick sort).
Autre exemple: Faire une recherche linéaire dans
un grand tableau de données sera toujours plus lent
que de faire une recherche dichotomique ou avec une hash
table.
Dans tous les cas, l'amélioration des perfs passe par de
meilleures structures/meilleurs algos/meilleures fonctions.
Donc pour répondre à ta question: ce type d'optimisation
par compilation est totalement inutile.
Bonjour jean-marc,
jean-marc a écrit :"Barsalou" wrote in message
news:%23$
Pour une fois, tu me permettras d'être en désaccord avec toi.
Non pas sur le fait qu'il faille un algorithme performant et adapté,
là je suis d'accord, c'est la base.
Mais sur les possibilités d'optimisation intégrées à un compilateur.
Je parle là en général, pas de VB en particulier ;-) .
Là aussi, il peut être utile de tester. Bien que les processeurs soient
de plus en plus puissants, indiquer le type de processeur par exemple
permet d'utiliser les instructions les plus performantes. J'admets que
pour VB, cette option est peut être obsolète vu son âge. D'autres
options, comme certains contrôles (dans les options avancées) peuvent
être intéressantes, bien qu'il faille pour le coup un code irréprochable
(Je n'ai pas testé ces options sous VB)
Par contre, et toujours de *manière générale* , le choix entre
pseudo-code (ou code interprété) et code natif, peut ne pas être neutre
du tout. Je prends un exemple concret, bien qu'ancien. Il existe des
langages multi plate-formes; pour des raisons de distribution, il est
intéressant de choisir le pseudo-code qui sera identique, car interprété
par un Run-Time approprié à chaque plate-forme. Si l'on choisit du code
natif, il faut deux distributions, car le code est, d'une part
interprété directement par le processeur, mais il faut qu'il soit
reconnu comme un exécutable valide par le système d'exploitation (et la,
point de normes, chacun son format). Et si je poursuis avec cet exemple
où les plates-formes étaient d'une part MS-DOS et d'autre par UNIX, on
avait (1995) d'un côté du code 8/16 bits en mode réel pour le premier,
et du code 32 bits en mode protégé pour l'autre. Je te garantis que ça
fait une différence
J'admets que dans ce cas, il est également difficile de juger de la part
de responsabilité du système d'exploitation.
Je te rappelle également les temps anciens des 286, et 386, où il était
bon de choisir le modèle adéquat entre Small (.exe ou .com), Medium ou
Large), et éventuellement d'indiquer la bonne librairie mathématique.
Les processeurs i287 et i387 n'étant pas toujours présent, car
excessivement cher, le compilateur générait soit des instructions
machines x87, soit utilisaient des librairies appropriées (Small, Medium
ou Large) exécutées par le processeur central, soit les deux. De
mémoire, un 80287, lors de sa sortie coutait plusieurs milliers de
francs (1985). Mais les gains de temps étaient très impressionnant
(de plusieurs minutes à quelques secondes pour certains calcul)
Bon d'accord, maintenant les processeurs mathématiques sont intégrés aux
Pentium, Itanium, etc... et le problème se déplace plutôt vers les cartes
graphiques (DirectX, Open GL)
PS : Je ne te ferais pas l'affront de te rappeler la foultitude d'options
de compilation et d'édition de liens de Cl (Visual C). Auraient ils mis
cela à disposition si ça ne servait vraiment à rien ? ;-)
Bonjour jean-marc,
jean-marc a écrit :
"Barsalou" <ericMettreUnPointbarsalou@wanadoo.fr> wrote in message
news:%23$CjAi6aHHA.4832@TK2MSFTNGP02.phx.gbl...
Pour une fois, tu me permettras d'être en désaccord avec toi.
Non pas sur le fait qu'il faille un algorithme performant et adapté,
là je suis d'accord, c'est la base.
Mais sur les possibilités d'optimisation intégrées à un compilateur.
Je parle là en général, pas de VB en particulier ;-) .
Là aussi, il peut être utile de tester. Bien que les processeurs soient
de plus en plus puissants, indiquer le type de processeur par exemple
permet d'utiliser les instructions les plus performantes. J'admets que
pour VB, cette option est peut être obsolète vu son âge. D'autres
options, comme certains contrôles (dans les options avancées) peuvent
être intéressantes, bien qu'il faille pour le coup un code irréprochable
(Je n'ai pas testé ces options sous VB)
Par contre, et toujours de *manière générale* , le choix entre
pseudo-code (ou code interprété) et code natif, peut ne pas être neutre
du tout. Je prends un exemple concret, bien qu'ancien. Il existe des
langages multi plate-formes; pour des raisons de distribution, il est
intéressant de choisir le pseudo-code qui sera identique, car interprété
par un Run-Time approprié à chaque plate-forme. Si l'on choisit du code
natif, il faut deux distributions, car le code est, d'une part
interprété directement par le processeur, mais il faut qu'il soit
reconnu comme un exécutable valide par le système d'exploitation (et la,
point de normes, chacun son format). Et si je poursuis avec cet exemple
où les plates-formes étaient d'une part MS-DOS et d'autre par UNIX, on
avait (1995) d'un côté du code 8/16 bits en mode réel pour le premier,
et du code 32 bits en mode protégé pour l'autre. Je te garantis que ça
fait une différence
J'admets que dans ce cas, il est également difficile de juger de la part
de responsabilité du système d'exploitation.
Je te rappelle également les temps anciens des 286, et 386, où il était
bon de choisir le modèle adéquat entre Small (.exe ou .com), Medium ou
Large), et éventuellement d'indiquer la bonne librairie mathématique.
Les processeurs i287 et i387 n'étant pas toujours présent, car
excessivement cher, le compilateur générait soit des instructions
machines x87, soit utilisaient des librairies appropriées (Small, Medium
ou Large) exécutées par le processeur central, soit les deux. De
mémoire, un 80287, lors de sa sortie coutait plusieurs milliers de
francs (1985). Mais les gains de temps étaient très impressionnant
(de plusieurs minutes à quelques secondes pour certains calcul)
Bon d'accord, maintenant les processeurs mathématiques sont intégrés aux
Pentium, Itanium, etc... et le problème se déplace plutôt vers les cartes
graphiques (DirectX, Open GL)
PS : Je ne te ferais pas l'affront de te rappeler la foultitude d'options
de compilation et d'édition de liens de Cl (Visual C). Auraient ils mis
cela à disposition si ça ne servait vraiment à rien ? ;-)
Bonjour jean-marc,
jean-marc a écrit :"Barsalou" wrote in message
news:%23$
Pour une fois, tu me permettras d'être en désaccord avec toi.
Non pas sur le fait qu'il faille un algorithme performant et adapté,
là je suis d'accord, c'est la base.
Mais sur les possibilités d'optimisation intégrées à un compilateur.
Je parle là en général, pas de VB en particulier ;-) .
Là aussi, il peut être utile de tester. Bien que les processeurs soient
de plus en plus puissants, indiquer le type de processeur par exemple
permet d'utiliser les instructions les plus performantes. J'admets que
pour VB, cette option est peut être obsolète vu son âge. D'autres
options, comme certains contrôles (dans les options avancées) peuvent
être intéressantes, bien qu'il faille pour le coup un code irréprochable
(Je n'ai pas testé ces options sous VB)
Par contre, et toujours de *manière générale* , le choix entre
pseudo-code (ou code interprété) et code natif, peut ne pas être neutre
du tout. Je prends un exemple concret, bien qu'ancien. Il existe des
langages multi plate-formes; pour des raisons de distribution, il est
intéressant de choisir le pseudo-code qui sera identique, car interprété
par un Run-Time approprié à chaque plate-forme. Si l'on choisit du code
natif, il faut deux distributions, car le code est, d'une part
interprété directement par le processeur, mais il faut qu'il soit
reconnu comme un exécutable valide par le système d'exploitation (et la,
point de normes, chacun son format). Et si je poursuis avec cet exemple
où les plates-formes étaient d'une part MS-DOS et d'autre par UNIX, on
avait (1995) d'un côté du code 8/16 bits en mode réel pour le premier,
et du code 32 bits en mode protégé pour l'autre. Je te garantis que ça
fait une différence
J'admets que dans ce cas, il est également difficile de juger de la part
de responsabilité du système d'exploitation.
Je te rappelle également les temps anciens des 286, et 386, où il était
bon de choisir le modèle adéquat entre Small (.exe ou .com), Medium ou
Large), et éventuellement d'indiquer la bonne librairie mathématique.
Les processeurs i287 et i387 n'étant pas toujours présent, car
excessivement cher, le compilateur générait soit des instructions
machines x87, soit utilisaient des librairies appropriées (Small, Medium
ou Large) exécutées par le processeur central, soit les deux. De
mémoire, un 80287, lors de sa sortie coutait plusieurs milliers de
francs (1985). Mais les gains de temps étaient très impressionnant
(de plusieurs minutes à quelques secondes pour certains calcul)
Bon d'accord, maintenant les processeurs mathématiques sont intégrés aux
Pentium, Itanium, etc... et le problème se déplace plutôt vers les cartes
graphiques (DirectX, Open GL)
PS : Je ne te ferais pas l'affront de te rappeler la foultitude d'options
de compilation et d'édition de liens de Cl (Visual C). Auraient ils mis
cela à disposition si ça ne servait vraiment à rien ? ;-)
Il n'y a rien non plus dans les propriétés du projet.
Cela dit j'ai fait de mon mieux pour optimiser le code et je voulais
simplement savoir si je pouvais gagner quelque chose en plus !
Il n'y a rien non plus dans les propriétés du projet.
Cela dit j'ai fait de mon mieux pour optimiser le code et je voulais
simplement savoir si je pouvais gagner quelque chose en plus !
Il n'y a rien non plus dans les propriétés du projet.
Cela dit j'ai fait de mon mieux pour optimiser le code et je voulais
simplement savoir si je pouvais gagner quelque chose en plus !
CompilationType était à -1. Je l'ai mis à 0 et compilé, mais
l'exécutable a exactement les mêmes 815104 octets de long, donc cela
ne sert à rien de bidouiller le vbp.
Merci quand même.
CompilationType était à -1. Je l'ai mis à 0 et compilé, mais
l'exécutable a exactement les mêmes 815104 octets de long, donc cela
ne sert à rien de bidouiller le vbp.
Merci quand même.
CompilationType était à -1. Je l'ai mis à 0 et compilé, mais
l'exécutable a exactement les mêmes 815104 octets de long, donc cela
ne sert à rien de bidouiller le vbp.
Merci quand même.