Optimisation générale du code

Le
Albert P.
Bonjour,

Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit pour "s'usinagazifier" il faut dire que
l'appli a été créé en 5.5 avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.

J'aurais donc besoin d'un petit retour d'expérience de votre part :

Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?

Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N

autres cas
fin

ou

Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin

De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?

Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.

Merci d'avance pour vos avis éclairés.

Albert P.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Daniel
Le #19136511
Albert P. a écrit :
Bonjour,

Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.

J'aurais donc besoin d'un petit retour d'expérience de votre part :

Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?

Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N

autres cas
fin

ou

Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin



je ne sais pas si en terme de performance si il y a une influence, par
contre il est évident qu'il est bien plus simple de maintenir un code
faisant appel à des fonctions


De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?



Plus il y a de champs, plus la fenêtre mettra du temps à s'initialiser.
L'utilisateur doit-il voir en même temps tous ces champs ?

Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.

Merci d'avance pour vos avis éclairés.

Albert P.






--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
titou44
Le #19136501
Albert P. a couché sur son écran :
Bonjour,

Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.

J'aurais donc besoin d'un petit retour d'expérience de votre part :

Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?

Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N

autres cas
fin

ou

Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin

De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?

Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.

Merci d'avance pour vos avis éclairés.

Albert P.



bonsoir

pour la maintenance il n'y pa pas photo.

même dans le code principal, j'aime avoir une succession de fonctions

trait1()
trait2()
...
cela oblige à structurer le code.

concernant la fenêtre, quand il y a trop de champs, j'utilise les
onglets. très pratique pour l'utilisateur !

cdt
titou44 chez freesurf.fr
STASZEWSKI André
Le #19137451
Bonjour,

"titou44"
Albert P. a couché sur son écran :
Bonjour,

Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il
ne nous est pas encore possible de recommencer un développement à 0.

J'aurais donc besoin d'un petit retour d'expérience de votre part :

Par exemple, pour une fonction gigantissime de quelques centaines de
lignes (nombreux selons imbriqués) serait-il plus performant d'isoler les
codes des différents cas dans des procedures séparées, la procedure
principale ne contenant que le selon principal et l'appel aux fonctions
secondaires ?

Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N

autres cas
fin

ou

Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin

De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?

Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.

Merci d'avance pour vos avis éclairés.

Albert P.



bonsoir

pour la maintenance il n'y pa pas photo.

même dans le code principal, j'aime avoir une succession de fonctions

trait1()
trait2()
...
cela oblige à structurer le code.

concernant la fenêtre, quand il y a trop de champs, j'utilise les onglets.
très pratique pour l'utilisateur !



Oui mais pour le temps d'initialisation, ça ne change rien, car les champs
s'initialisent quand même dans les volets inactifs.
Cas du remplissage d'un combo par exemple...

cdt
titou44 chez freesurf.fr




--
Cordialement,
André STASZEWSKI
(Gratuit) Photo Visu et Cut Data Radars sur
http://pagesperso-orange.fr/mdev/
Pour me contacter, cliquez ici :
http://cerbermail.com/?OT0Wnwyzph
JeAn-PhI
Le #19138711
STASZEWSKI André a couché sur son écran :
Bonjour,

"titou44"
Albert P. a couché sur son écran :
Bonjour,

Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.

J'aurais donc besoin d'un petit retour d'expérience de votre part :

Par exemple, pour une fonction gigantissime de quelques centaines de
lignes (nombreux selons imbriqués) serait-il plus performant d'isoler les
codes des différents cas dans des procedures séparées, la procedure
principale ne contenant que le selon principal et l'appel aux fonctions
secondaires ?

Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N

autres cas
fin

ou

Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin

De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?

Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.

Merci d'avance pour vos avis éclairés.

Albert P.



bonsoir

pour la maintenance il n'y pa pas photo.

même dans le code principal, j'aime avoir une succession de fonctions

trait1()
trait2()
...
cela oblige à structurer le code.

concernant la fenêtre, quand il y a trop de champs, j'utilise les onglets.
très pratique pour l'utilisateur !



Oui mais pour le temps d'initialisation, ça ne change rien, car les champs
s'initialisent quand même dans les volets inactifs.
Cas du remplissage d'un combo par exemple...



vous pouvez charger que le volet actif

--
Cordialement JeAn-PhI
BrnWrk
Le #19149761
Albert P. a couché sur son écran :
Bonjour,

Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.

J'aurais donc besoin d'un petit retour d'expérience de votre part :

Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?

Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N

autres cas
fin

ou

Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin



Comme dit, c'est surtout la maintenance/lisibilité que tu vas améliorer
en modifiant ton code. Niveau perfomance il faut voir dans le détail...


De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?



Pour avoir été confronté au problème, à savoir une fenêtre multi plan
avec chacun plusieurs onglets ( et donc plus de 700-800 champs ) il y a
principalement 2 solutions et demi je crois :
- Faire du MDI : j'ai opté pour cette solution, ca complique certaines
interactions entre fenêtre principale et sous fenêtres mais une fois
l'ensemble bien goupillé c'est vraiment très agréable / léger / rapide
- Fenêtres internes Windev : j'aimerai bien essayé pour ma fenêtre
principale, je suis curieux de voir le résultat, ca parait plus propre
que du MDI ( qui est dégueu sous Windev avec impossibilité de faire
disparaitre proprement le cadre droit et inférieur ) s'il n'y a pas
besoin de switcher entre les fenêtres mais niveau performance je ne
connais pas suffisament.
- Ouvrir des sous fenêtres pour certains modules afin d'alléger la
fenêtre principale, ca s'y prête pour certains, pas pour tout...
Albert P.
Le #19150281
Merci pour vos réponses.

Je suis entièrement d'accord avec vous tous pour la question "lisibilitée /
maintenance"

Je vais faire quelques tests (morceler le code en procedures) et je
posterais ici les résultats de mes tests ... concluants ou pas sur
l'amélioration des perfs.

Albert P.
Albert P.
Le #19165071
Bonjour à tous.

Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour de
questions de maintenance, pas de différence ... ou alors tellement minime
que l'analyseur de performance ne permet pas de les détecter.

Une question néanmoins, avez vous trouver des solutions pour optimiser les
phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement pour
l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au moteur
d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais le
résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).

Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?

Albert P.
BrnWrk
Le #19165131
Albert P. avait écrit le 22/04/2009 :
Bonjour à tous.

Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour de
questions de maintenance, pas de différence ... ou alors tellement minime que
l'analyseur de performance ne permet pas de les détecter.

Une question néanmoins, avez vous trouver des solutions pour optimiser les
phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement pour
l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au moteur
d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais le
résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).

Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?

Albert P.



Des caracs particulières à tes fenêtres ?
Code d'init lourd, multitude de champs, plusieurs tables avec des
requêtes lourdes ?

++
Albert P.
Le #19165621
"BrnWrk"
Albert P. avait écrit le 22/04/2009 :
Bonjour à tous.

Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour
de questions de maintenance, pas de différence ... ou alors tellement
minime que l'analyseur de performance ne permet pas de les détecter.

Une question néanmoins, avez vous trouver des solutions pour optimiser
les phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement
pour l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au
moteur d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais
le résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).

Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?

Albert P.



Des caracs particulières à tes fenêtres ?
Code d'init lourd, multitude de champs, plusieurs tables avec des requêtes
lourdes ?

++





Salut,

Pas particulièrement, cela se produit même pour des fenêtres "info" c'est à
dire : 1 champ libellé + 1 bouton fermer. Lors de la fermeture de cette
fenêtre "info", le raffraichissement de la fenêtre appellante se fait par
morceaux ...

Les machines sur lesquelles le phénomène se produit ne sont bien sur pas
très puissante (carte graphique de base, mémoire minimale) ... mais c'est
quand même troublant car cela ne se produit qu'avec des Executables générés
avec windev.

Albert P.
Daniel
Le #19165721
Albert P. a écrit :
"BrnWrk"
Albert P. avait écrit le 22/04/2009 :
Bonjour à tous.

Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour
de questions de maintenance, pas de différence ... ou alors tellement
minime que l'analyseur de performance ne permet pas de les détecter.

Une question néanmoins, avez vous trouver des solutions pour optimiser
les phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement
pour l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au
moteur d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais
le résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).

Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?

Albert P.


Des caracs particulières à tes fenêtres ?
Code d'init lourd, multitude de champs, plusieurs tables avec des requêtes
lourdes ?

++





Salut,

Pas particulièrement, cela se produit même pour des fenêtres "info" c'est à
dire : 1 champ libellé + 1 bouton fermer. Lors de la fermeture de cette
fenêtre "info", le raffraichissement de la fenêtre appellante se fait par
morceaux ...

Les machines sur lesquelles le phénomène se produit ne sont bien sur pas
très puissante (carte graphique de base, mémoire minimale) ... mais c'est
quand même troublant car cela ne se produit qu'avec des Executables générés
avec windev.

Albert P.





Cela vient souvent des fonds ou gabarits.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Publicité
Poster une réponse
Anonyme