Lorsque je lance mon exe ( vb6 ) depuis l'IDE les temps de réponses sont
correctes. Mais lorsque je la compile et la lance à part, le temps
d'exécution deviennent catastrophiques ( 2 s ---> deviennent 55 s environ )
Mon appli utilise ADO, msflexgrid et des requêtes sql basiques.
Quelqu'un aurait-il une idée d'où peut venir le problème ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
LE TROLL
Bonjour,
Tu peux déjà tenter de localiser ce qui provoque la lenteur, un tri trop long, etc... Puis améliorer en rapidité quand c'est identifié... ------
"yoplait" a écrit dans le message de news: cnomu0$juv$
Bonjour,
Lorsque je lance mon exe ( vb6 ) depuis l'IDE les temps de réponses sont correctes. Mais lorsque je la compile et la lance à part, le temps d'exécution deviennent catastrophiques ( 2 s ---> deviennent 55 s environ )
Mon appli utilise ADO, msflexgrid et des requêtes sql basiques.
Quelqu'un aurait-il une idée d'où peut venir le problème ?
Merci
Bonjour,
Tu peux déjà tenter de localiser ce qui provoque la lenteur, un tri trop
long, etc... Puis améliorer en rapidité quand c'est identifié...
------
"yoplait" <e@e.net> a écrit dans le message de news:
cnomu0$juv$1@biggoron.nerim.net...
Bonjour,
Lorsque je lance mon exe ( vb6 ) depuis l'IDE les temps de réponses sont
correctes. Mais lorsque je la compile et la lance à part, le temps
d'exécution deviennent catastrophiques ( 2 s ---> deviennent 55 s
environ )
Mon appli utilise ADO, msflexgrid et des requêtes sql basiques.
Quelqu'un aurait-il une idée d'où peut venir le problème ?
Tu peux déjà tenter de localiser ce qui provoque la lenteur, un tri trop long, etc... Puis améliorer en rapidité quand c'est identifié... ------
"yoplait" a écrit dans le message de news: cnomu0$juv$
Bonjour,
Lorsque je lance mon exe ( vb6 ) depuis l'IDE les temps de réponses sont correctes. Mais lorsque je la compile et la lance à part, le temps d'exécution deviennent catastrophiques ( 2 s ---> deviennent 55 s environ )
Mon appli utilise ADO, msflexgrid et des requêtes sql basiques.
Quelqu'un aurait-il une idée d'où peut venir le problème ?
Merci
Jean-Marc
"yoplait" a écrit dans le message de news:cnomu0$juv$
Bonjour,
Lorsque je lance mon exe ( vb6 ) depuis l'IDE les temps de réponses sont correctes. Mais lorsque je la compile et la lance à part, le temps d'exécution deviennent catastrophiques ( 2 s ---> deviennent 55 s
environ )
Mon appli utilise ADO, msflexgrid et des requêtes sql basiques.
Quelqu'un aurait-il une idée d'où peut venir le problème ?
Hello,
Curieux? C'est en général l'inverse qui se produit. Je ne sais pas d'ou ça peut venir, mais si je devais investiguer, je mettrais des traces dans mon programme aux différentes étapes, en écrivant dans un fichier de log:
- l'endroit ou je suis dans le programme - l'heure ou la sortie de Timer en Double
Puis j'exécuterais dans l'IDE et en dehors, et la comparaison des 2 log files devrait te dire ou se trouvent les différences.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"yoplait" <e@e.net> a écrit dans le message de
news:cnomu0$juv$1@biggoron.nerim.net...
Bonjour,
Lorsque je lance mon exe ( vb6 ) depuis l'IDE les temps de réponses sont
correctes. Mais lorsque je la compile et la lance à part, le temps
d'exécution deviennent catastrophiques ( 2 s ---> deviennent 55 s
environ )
Mon appli utilise ADO, msflexgrid et des requêtes sql basiques.
Quelqu'un aurait-il une idée d'où peut venir le problème ?
Hello,
Curieux? C'est en général l'inverse qui se produit.
Je ne sais pas d'ou ça peut venir, mais si je devais investiguer, je
mettrais des traces dans mon programme aux différentes étapes, en
écrivant dans un fichier de log:
- l'endroit ou je suis dans le programme
- l'heure ou la sortie de Timer en Double
Puis j'exécuterais dans l'IDE et en dehors, et la comparaison des 2 log
files devrait te dire ou se trouvent les différences.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"yoplait" a écrit dans le message de news:cnomu0$juv$
Bonjour,
Lorsque je lance mon exe ( vb6 ) depuis l'IDE les temps de réponses sont correctes. Mais lorsque je la compile et la lance à part, le temps d'exécution deviennent catastrophiques ( 2 s ---> deviennent 55 s
environ )
Mon appli utilise ADO, msflexgrid et des requêtes sql basiques.
Quelqu'un aurait-il une idée d'où peut venir le problème ?
Hello,
Curieux? C'est en général l'inverse qui se produit. Je ne sais pas d'ou ça peut venir, mais si je devais investiguer, je mettrais des traces dans mon programme aux différentes étapes, en écrivant dans un fichier de log:
- l'endroit ou je suis dans le programme - l'heure ou la sortie de Timer en Double
Puis j'exécuterais dans l'IDE et en dehors, et la comparaison des 2 log files devrait te dire ou se trouvent les différences.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
yoplait
"Jean-Marc" a écrit dans le message de news: 41a05a7f$0$13456$
"yoplait" a écrit dans le message de news:cnomu0$juv$ Hello,
Curieux? C'est en général l'inverse qui se produit. Je ne sais pas d'ou ça peut venir, mais si je devais investiguer, je mettrais des traces dans mon programme aux différentes étapes, en écrivant dans un fichier de log:
- l'endroit ou je suis dans le programme - l'heure ou la sortie de Timer en Double
Puis j'exécuterais dans l'IDE et en dehors, et la comparaison des 2 log files devrait te dire ou se trouvent les différences.
Merci pour les astuces.
Après vérification, le goulot se trouve au niveau du remplissage de la MSFlexgrid... Ça prend un temps horriblement long en version compilée alors que sous l'IDE c'est rapide. À l'utilisation en compilé aussi les temps de réaction sont plutôt longs ( coloration de cellules, etc.. )
Je soupçonne fortement le framework .NET d'y être pour quelque chose. Ma config :
Win XP Pro Sp1, vb6 + sp6, .Net 1.1
Si quelqu'un avait une idée, ça me sauverait quelques nuits blanches :-)
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de news:
41a05a7f$0$13456$ba620e4c@news.skynet.be...
"yoplait" <e@e.net> a écrit dans le message de
news:cnomu0$juv$1@biggoron.nerim.net...
Hello,
Curieux? C'est en général l'inverse qui se produit.
Je ne sais pas d'ou ça peut venir, mais si je devais investiguer, je
mettrais des traces dans mon programme aux différentes étapes, en
écrivant dans un fichier de log:
- l'endroit ou je suis dans le programme
- l'heure ou la sortie de Timer en Double
Puis j'exécuterais dans l'IDE et en dehors, et la comparaison des 2 log
files devrait te dire ou se trouvent les différences.
Merci pour les astuces.
Après vérification, le goulot se trouve au niveau du remplissage de la
MSFlexgrid... Ça prend un temps horriblement long en version compilée alors
que sous l'IDE c'est rapide. À l'utilisation en compilé aussi les temps de
réaction sont plutôt longs ( coloration de cellules, etc.. )
Je soupçonne fortement le framework .NET d'y être pour quelque chose. Ma
config :
Win XP Pro Sp1, vb6 + sp6, .Net 1.1
Si quelqu'un avait une idée, ça me sauverait quelques nuits blanches :-)
"Jean-Marc" a écrit dans le message de news: 41a05a7f$0$13456$
"yoplait" a écrit dans le message de news:cnomu0$juv$ Hello,
Curieux? C'est en général l'inverse qui se produit. Je ne sais pas d'ou ça peut venir, mais si je devais investiguer, je mettrais des traces dans mon programme aux différentes étapes, en écrivant dans un fichier de log:
- l'endroit ou je suis dans le programme - l'heure ou la sortie de Timer en Double
Puis j'exécuterais dans l'IDE et en dehors, et la comparaison des 2 log files devrait te dire ou se trouvent les différences.
Merci pour les astuces.
Après vérification, le goulot se trouve au niveau du remplissage de la MSFlexgrid... Ça prend un temps horriblement long en version compilée alors que sous l'IDE c'est rapide. À l'utilisation en compilé aussi les temps de réaction sont plutôt longs ( coloration de cellules, etc.. )
Je soupçonne fortement le framework .NET d'y être pour quelque chose. Ma config :
Win XP Pro Sp1, vb6 + sp6, .Net 1.1
Si quelqu'un avait une idée, ça me sauverait quelques nuits blanches :-)
Jean-Marc
"yoplait" a écrit dans le message de news:cnpovh$vh2$
"Jean-Marc" a écrit dans le message de
news:
41a05a7f$0$13456$ > "yoplait" a écrit dans le message de > news:cnomu0$juv$ > Hello, > > Curieux? C'est en général l'inverse qui se produit. > Je ne sais pas d'ou ça peut venir, mais si je devais investiguer, je > mettrais des traces dans mon programme aux différentes étapes, en > écrivant dans un fichier de log: > > - l'endroit ou je suis dans le programme > - l'heure ou la sortie de Timer en Double > > Puis j'exécuterais dans l'IDE et en dehors, et la comparaison des 2 log > files devrait te dire ou se trouvent les différences.
Merci pour les astuces.
Après vérification, le goulot se trouve au niveau du remplissage de la MSFlexgrid... Ça prend un temps horriblement long en version compilée
alors
que sous l'IDE c'est rapide. À l'utilisation en compilé aussi les temps de réaction sont plutôt longs ( coloration de cellules, etc.. )
Ouais, déjà eu ce genre de choses. J'essaierais ceci (pas nécessairement dans cet ordre, pas nécessairement tout en même temps, faut voir):
AVANT le début du chargement des données, changer les pptés de la MSFlexGrid:
- mettre Redraw à False - mettre Enables à False - si le design le permet, mettre carrément Visible à False
Une fois les données chargées, remettre les propriétés à leurs valeurs initiales.
Je sais pas combien tu vas gagner, mais tu vas gagner, ça c'est sur. Je suis intéressé par les résultats :-)
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"yoplait" <e@e.net> a écrit dans le message de
news:cnpovh$vh2$1@biggoron.nerim.net...
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de
news:
41a05a7f$0$13456$ba620e4c@news.skynet.be...
> "yoplait" <e@e.net> a écrit dans le message de
> news:cnomu0$juv$1@biggoron.nerim.net...
> Hello,
>
> Curieux? C'est en général l'inverse qui se produit.
> Je ne sais pas d'ou ça peut venir, mais si je devais investiguer, je
> mettrais des traces dans mon programme aux différentes étapes, en
> écrivant dans un fichier de log:
>
> - l'endroit ou je suis dans le programme
> - l'heure ou la sortie de Timer en Double
>
> Puis j'exécuterais dans l'IDE et en dehors, et la comparaison des 2 log
> files devrait te dire ou se trouvent les différences.
Merci pour les astuces.
Après vérification, le goulot se trouve au niveau du remplissage de la
MSFlexgrid... Ça prend un temps horriblement long en version compilée
alors
que sous l'IDE c'est rapide. À l'utilisation en compilé aussi les temps de
réaction sont plutôt longs ( coloration de cellules, etc.. )
Ouais, déjà eu ce genre de choses. J'essaierais ceci (pas
nécessairement dans cet ordre, pas nécessairement tout en
même temps, faut voir):
AVANT le début du chargement des données, changer les pptés
de la MSFlexGrid:
- mettre Redraw à False
- mettre Enables à False
- si le design le permet, mettre carrément Visible à False
Une fois les données chargées, remettre les propriétés à leurs valeurs
initiales.
Je sais pas combien tu vas gagner, mais tu vas gagner, ça c'est sur. Je suis
intéressé par les résultats :-)
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"yoplait" a écrit dans le message de news:cnpovh$vh2$
"Jean-Marc" a écrit dans le message de
news:
41a05a7f$0$13456$ > "yoplait" a écrit dans le message de > news:cnomu0$juv$ > Hello, > > Curieux? C'est en général l'inverse qui se produit. > Je ne sais pas d'ou ça peut venir, mais si je devais investiguer, je > mettrais des traces dans mon programme aux différentes étapes, en > écrivant dans un fichier de log: > > - l'endroit ou je suis dans le programme > - l'heure ou la sortie de Timer en Double > > Puis j'exécuterais dans l'IDE et en dehors, et la comparaison des 2 log > files devrait te dire ou se trouvent les différences.
Merci pour les astuces.
Après vérification, le goulot se trouve au niveau du remplissage de la MSFlexgrid... Ça prend un temps horriblement long en version compilée
alors
que sous l'IDE c'est rapide. À l'utilisation en compilé aussi les temps de réaction sont plutôt longs ( coloration de cellules, etc.. )
Ouais, déjà eu ce genre de choses. J'essaierais ceci (pas nécessairement dans cet ordre, pas nécessairement tout en même temps, faut voir):
AVANT le début du chargement des données, changer les pptés de la MSFlexGrid:
- mettre Redraw à False - mettre Enables à False - si le design le permet, mettre carrément Visible à False
Une fois les données chargées, remettre les propriétés à leurs valeurs initiales.
Je sais pas combien tu vas gagner, mais tu vas gagner, ça c'est sur. Je suis intéressé par les résultats :-)
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Patrick Philippot
yoplait wrote:
Je soupçonne fortement le framework .NET d'y être pour quelque chose.
Bonjour,
En aucune manière le framework .Net ne peut intervenir sur l'exécution d'un programme VB6. Le framework est constitué de DLLs qui sont chargées par les programmes .Net au moment de leur exécution. S'il n'y a pas de programmes .Net en cours d'exécution, l'influence de .Net sur les performances du système est nulle.
Comme le dit Jean-Marc, quand on remplit une liste ou un grille avec un grand nombre d'éléments, il faut systématiquement mettre Redraw à FALSE afin d'empêcher le rafraîchissement de l'écran à chaque article inséré. La manipulation de la propriété Redraw seule devrait suffire.
Ceci n'explique pas la différence de comportement entre IDE et version compilée. Je ne vois pas d'explication évidente sur ce point. Êtes-vous bien sûr que le programme est strictement identique dans les 2 cas? A moins que la MSFlexGrid ait un comportement différent en mode design. Ça serait surprenant mais c'est techniquement possible. Je n'ai pas d'infos là-dessus.
Si vous alimentez comme je le suppose votre grille depuis un Recordset, il y a un moyen d'accélérer encore plus le chargement des données avec la propriété Clip. Exemple:
'Sélection des lignes 5 à 8 sur n colonnes MSFlexGrid1.Row = 5 MSFlexGrid1.Col = 1 MSFlexGrid1.RowSel = 8 MSFlexGrid1.ColSel = rs.rdoColumns.Count 'Chargement de 4 lignes dans la zone sélectionnée MSFlexGrid1.Clip = rs.GetClipString(4)
En fait, la propriété Clip accepte toute chaîne délimitée par des tabs et contenant autant d'éléments que de colonnes à remplir par ligne.
Voir la doc de la propriété Clip.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
yoplait wrote:
Je soupçonne fortement le framework .NET d'y être pour quelque chose.
Bonjour,
En aucune manière le framework .Net ne peut intervenir sur l'exécution
d'un programme VB6. Le framework est constitué de DLLs qui sont chargées
par les programmes .Net au moment de leur exécution. S'il n'y a pas de
programmes .Net en cours d'exécution, l'influence de .Net sur les
performances du système est nulle.
Comme le dit Jean-Marc, quand on remplit une liste ou un grille avec un
grand nombre d'éléments, il faut systématiquement mettre Redraw à FALSE
afin d'empêcher le rafraîchissement de l'écran à chaque article inséré.
La manipulation de la propriété Redraw seule devrait suffire.
Ceci n'explique pas la différence de comportement entre IDE et version
compilée. Je ne vois pas d'explication évidente sur ce point. Êtes-vous
bien sûr que le programme est strictement identique dans les 2 cas? A
moins que la MSFlexGrid ait un comportement différent en mode design. Ça
serait surprenant mais c'est techniquement possible. Je n'ai pas d'infos
là-dessus.
Si vous alimentez comme je le suppose votre grille depuis un Recordset,
il y a un moyen d'accélérer encore plus le chargement des données avec
la propriété Clip. Exemple:
'Sélection des lignes 5 à 8 sur n colonnes
MSFlexGrid1.Row = 5
MSFlexGrid1.Col = 1
MSFlexGrid1.RowSel = 8
MSFlexGrid1.ColSel = rs.rdoColumns.Count
'Chargement de 4 lignes dans la zone sélectionnée
MSFlexGrid1.Clip = rs.GetClipString(4)
En fait, la propriété Clip accepte toute chaîne délimitée par des tabs
et contenant autant d'éléments que de colonnes à remplir par ligne.
Voir la doc de la propriété Clip.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Je soupçonne fortement le framework .NET d'y être pour quelque chose.
Bonjour,
En aucune manière le framework .Net ne peut intervenir sur l'exécution d'un programme VB6. Le framework est constitué de DLLs qui sont chargées par les programmes .Net au moment de leur exécution. S'il n'y a pas de programmes .Net en cours d'exécution, l'influence de .Net sur les performances du système est nulle.
Comme le dit Jean-Marc, quand on remplit une liste ou un grille avec un grand nombre d'éléments, il faut systématiquement mettre Redraw à FALSE afin d'empêcher le rafraîchissement de l'écran à chaque article inséré. La manipulation de la propriété Redraw seule devrait suffire.
Ceci n'explique pas la différence de comportement entre IDE et version compilée. Je ne vois pas d'explication évidente sur ce point. Êtes-vous bien sûr que le programme est strictement identique dans les 2 cas? A moins que la MSFlexGrid ait un comportement différent en mode design. Ça serait surprenant mais c'est techniquement possible. Je n'ai pas d'infos là-dessus.
Si vous alimentez comme je le suppose votre grille depuis un Recordset, il y a un moyen d'accélérer encore plus le chargement des données avec la propriété Clip. Exemple:
'Sélection des lignes 5 à 8 sur n colonnes MSFlexGrid1.Row = 5 MSFlexGrid1.Col = 1 MSFlexGrid1.RowSel = 8 MSFlexGrid1.ColSel = rs.rdoColumns.Count 'Chargement de 4 lignes dans la zone sélectionnée MSFlexGrid1.Clip = rs.GetClipString(4)
En fait, la propriété Clip accepte toute chaîne délimitée par des tabs et contenant autant d'éléments que de colonnes à remplir par ligne.
Voir la doc de la propriété Clip.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
yoplait
"Jean-Marc" a écrit dans le message de news: 41a06953$0$25056$
AVANT le début du chargement des données, changer les pptés de la MSFlexGrid:
- mettre Redraw à False - mettre Enables à False
Je remplissais déjà la grid comme ça. :-/
- si le design le permet, mettre carrément Visible à False
En essayant ça juste pour voir, je gagne environ 40-50% ( le temps passe de 55 s à 26-27s). Mais c'est toujours inacceptable...
Je sais pas combien tu vas gagner, mais tu vas gagner, ça c'est sur. Je
suis
intéressé par les résultats :-)
Eh ben... si je pouvais gagner autant que ce que l'IDE me fournit j'en serais ravi ;-)
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de news:
41a06953$0$25056$ba620e4c@news.skynet.be...
AVANT le début du chargement des données, changer les pptés
de la MSFlexGrid:
- mettre Redraw à False
- mettre Enables à False
Je remplissais déjà la grid comme ça. :-/
- si le design le permet, mettre carrément Visible à False
En essayant ça juste pour voir, je gagne environ 40-50% ( le temps passe de
55 s à 26-27s).
Mais c'est toujours inacceptable...
Je sais pas combien tu vas gagner, mais tu vas gagner, ça c'est sur. Je
suis
intéressé par les résultats :-)
Eh ben... si je pouvais gagner autant que ce que l'IDE me fournit j'en
serais ravi ;-)
"Jean-Marc" a écrit dans le message de news: 41a06953$0$25056$
AVANT le début du chargement des données, changer les pptés de la MSFlexGrid:
- mettre Redraw à False - mettre Enables à False
Je remplissais déjà la grid comme ça. :-/
- si le design le permet, mettre carrément Visible à False
En essayant ça juste pour voir, je gagne environ 40-50% ( le temps passe de 55 s à 26-27s). Mais c'est toujours inacceptable...
Je sais pas combien tu vas gagner, mais tu vas gagner, ça c'est sur. Je
suis
intéressé par les résultats :-)
Eh ben... si je pouvais gagner autant que ce que l'IDE me fournit j'en serais ravi ;-)
Jean-Marc
"Patrick Philippot" a écrit dans le message de news:
yoplait wrote:
<snip>
Si vous alimentez comme je le suppose votre grille depuis un Recordset, il y a un moyen d'accélérer encore plus le chargement des données avec la propriété Clip. Exemple:
<...>
En fait, la propriété Clip accepte toute chaîne délimitée par des tabs et contenant autant d'éléments que de colonnes à remplir par ligne.
Voir la doc de la propriété Clip.
Excellent le Clip. Je ne connaissais pas, c'est tout bon! Merci de l'info.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> a écrit dans le
message de news:e98Dkc7zEHA.1292@TK2MSFTNGP10.phx.gbl...
yoplait wrote:
<snip>
Si vous alimentez comme je le suppose votre grille depuis un Recordset,
il y a un moyen d'accélérer encore plus le chargement des données avec
la propriété Clip. Exemple:
<...>
En fait, la propriété Clip accepte toute chaîne délimitée par des tabs
et contenant autant d'éléments que de colonnes à remplir par ligne.
Voir la doc de la propriété Clip.
Excellent le Clip. Je ne connaissais pas, c'est tout bon!
Merci de l'info.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Patrick Philippot" a écrit dans le message de news:
yoplait wrote:
<snip>
Si vous alimentez comme je le suppose votre grille depuis un Recordset, il y a un moyen d'accélérer encore plus le chargement des données avec la propriété Clip. Exemple:
<...>
En fait, la propriété Clip accepte toute chaîne délimitée par des tabs et contenant autant d'éléments que de colonnes à remplir par ligne.
Voir la doc de la propriété Clip.
Excellent le Clip. Je ne connaissais pas, c'est tout bon! Merci de l'info.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
