Discussion :

[titou640]

Bonjour,

Aujourd'hui c'est une simple question:
Est il connu que l'utilisation de usercontrols imbriqués les uns dans les autres génèrent des lenteurs?
Je suis presque sûr d'avoir lu cela il y a quelques mois ... mais je n'arrive pas à remettre la main sur cette article .
Donc si vous pouviez me le confirmer, et/ou m'orienter vers des articles traitant de cela, ce serait cool.

Mon application est de plus en plus lente, or les seuls choses que j'ai faite ces dernières semaines sont des requêtes SQL (ajout, modif., suppression) et mise a jour de mes affichages.

Bien sûr, je pointe du doigt cette empilation de Uc, mais toutes les idées et autres pistes sont les bien venues.

Merci de votre aide.

[Thomas Lebrun]

Plus tu as de UserControls qui s'imbriquent, plus tu as d'objets visuels à rendre à l'écran donc effectivement, cela peut entrainer des lenteurs (mais bon, il faut vraiment en avoir bcp, bcp

[BenoitM]

Le plus "simple" est de logger le temps que prennent "chaque" opération.
un DateTime startTime=DateTime.Now au début d'une fonction et à la fin Log("Ma fonction a mis :"+ (DateTime.Now-startTime));
pour voir combien de temps prend l'acces au data

[titou640]

Ok, donc ce n'est pas avec une vingtaine de uc sur une profondeur de 4-5 que des lenteur de plusieurs seconde peuvent survenir je suppose? ... donc mon problème viens d'ailleurs ?!

Bon je vais recommencer à décortiquer l'appli compléte alors .

[Lordinaire]

Je ne pense pas que cela puisse avoir un impact aussi important sur les perfs. Par contre les appels aux requêtes SQL sont elles en asynchrones ?

[titou640]

BenoitM, je vais essayer de logger ainsi, on verra ce que çà donne

Lordinaire, non les requêtes ne sont pas asynchrone.
Suggérerais tu que ce sont les requêtes qui prendrais plusieurs seconde? Je vais logger le temps de cela aussi, mais il s'agit a chaque fois d'1 a 10 requêtes (pour la suppression par exemple) impactant une jusqu’à une dizaine de records contenant pas plus de 20 champs (petit calcule rapide 10 requêtes x 10 records x 20 champs = pas bien lourds selon moi) mais passant par une classe codée par quelqu'un d'autre, pour effectuer ces requêtes, je vais chercher les source et regarder ce qu'il y a dedans

[BenoitM]

avec les insert/update/delete/ tu peux aussi avoir des problèmes de lock mais bon.
Difficile de faire des pronostiques

[titou640]

Avec un peu (beaucoup) de délais, mais BenoitM avait raison, j'ai quand meme un problème de "Base de données"!
Du coup je suis plus dans la bonne section j'imagine :S (mais je ne sais pas comment, ou si je peux, déplacer mon sujet ).
Sur le conseil d'une connaissance j'ai essayer de mettre en place une transaction pour toutes les requêtes (en chaines) et le résultat à été surprenant :
- cela réduit le temps des UPDATEs et INSERTs (+/- 10 - 100 entrées) de 2-3s à 200ms, ca c'est cool !
- mais les DELETEs pour le même volume d'entrées cela prend toujours 3s :S

Je suis donc toujours preneur de tips ou conseils bien sur, ou si quelqu'un doit me dire: " mais c'est normal ! Le DELETE n'accepte pas la transaction ! " chose que je n'ai trouvé nulle part (j’entends la compatibilité de la transaction avec les différentes requêtes)

merci de votre aide.


-----------------------------------------------------------------
Petite Maj

J'ai eu l'idée de mettre des trigger dans la BdD (pour éviter de le faire dans le code de mon IHM) et ainsi faire les suppressions en chaine de "manière intelligente".
Sauf que ça na pas l'aire de marcher, comment savoir si le trigger est déclenché? Savoir si il a échoué ou si il ne s'est pas déclenché?

(une phase contient 0..* courbes)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
delimiter |
CREATE TRIGGER TRG_DEL_PHASE BEFORE DELETE 
ON phase
FOR EACH ROW BEGIN
DELETE FROM courbe WHERE phase_id = OLD.id;
END;
|
delimiter;

Merci.