Discussion :

[stdebordeau]

Salut,

Dans une application lié à une base de donnée, comment feriez vous pour optimiser les délais de chargement ?. je m'explique:

Dans ma configuration actuelle, à chaque ouverture d'un form, il y'a une longue procédure de chargement des tables liées (Bcp de datagridview liés, et dataset fortement typé), ce qui fait que les formulaires mettent du temps à apparaître (entre 5 et 15s).

j'ai pensé à une procédure exclusivement dédiée au chargement et qui chargerais toutes les tables une bonne fois au lancement de l'application, avec des objets instanciés dans des variables publiques accéssibles à toutes les classes.

Mais j'ai pas encore essayé, je voudrais avant m'enrichir de vos multiples expériences sur le sujet.

[roster]

j'ai pensé à une procédure exclusivement dédiée au chargement et qui chargerais toutes les tables une bonne fois au lancement de l'application, avec des objets instanciés dans des variables publiques accéssibles à toutes les classes.

Oui, dans un thread séparé. Après, mettre tout en variable publique, ce n'est peut-être pas le top. Mais avec le peu d'expérience que j'ai dans ce domaine, j'aurai fait comme çà.

[Wapi_gui]

Bonjour,

Euh, franchement, si tu peux faire autrement, n'hésites pas... C'est ce que j'avais fait sur mon application en stage, et quand mon maitre de stage l'a vu, il n'était pas très content. Son conseil c'est plutôt d'ouvrir la base de données le moins possible, de faire pleins de procédures stockées... Bref, de charger à fond la base, et de faire quelque chose de très léger du côté de .Net. Après, il y a peut-être des gens qui ont plus d'expériences en la matière...

[stdebordeau]

merci roster, à propos petite question bête (fais moi grace)
c'est quoi un thread ?

[stdebordeau]

merci aussi à toi wapi gui.
en fait le fait de charger à fonds la base comme tu dis ne change rien au problème puisqu'il faut toujours faire des appels.

[Philippe Vialatte]

Euh, franchement, si tu peux faire autrement, n'hésites pas... C'est ce que j'avais fait sur mon application en stage, et quand mon maitre de stage l'a vu, il n'était pas très content. Son conseil c'est plutôt d'ouvrir la base de données le moins possible

+1...voir +1000

Normalement, le cout d'acces a une base de donnees est assez ridicule, tout charge cote client pose le probleme de la synchro des donnees, charge le client, surcherge la base si plusieurs clients lancent leur appli au meme moment, etc...

Dans une conf "normale", il faut ouvrir la connection le plus tard possible, la refermer le plus tot possible, et ne rapatrier que les donnees dont tu as besoin pour travailler...

[roster]

Dans une conf "normale", il faut ouvrir la connection le plus tard possible, la refermer le plus tot possible, et ne rapatrier que les donnees dont tu as besoin pour travailler...

Dis comme çà, cela parait logique!
Merci pour le conseil.

[stdebordeau]

Donc en résumé ma solution n'est pas la bonne?

[roster]

Donc en résumé ma solution n'est pas la bonne?

Pas la meilleure en tout cas!


Pour répondre à ton autre question zapée par mégarde:

c'est quoi un thread ?

Threads

Cela permet de lancer des méthodes de façon asynchrone, sans freezer l'appli.
Mais dans le cas ou l'on ne peut savoir quelles arguments lancer, cas d'un tri dans la BD où l'on ne connait pas par avance les données à trier, cela n'a sûrement aucun interet.

[stdebordeau]

J'ai tenté une petite parade qui marche plutot bien.
dans un module j'écris une procedure qui charge toutes les tables du dataset. cette procedure est appelé au lançement de l'application. c'est donc lent au lancement mais c'est préférable.

ensuite je travail avec mes autres classes de manière habituel. c'est à dire que chaque form charge encore les tables dont il a besoin, mais là le chargement est plus rapide. les formulaires s'ouvre donc plus vite.

en réalité je ne sais pas pourquoi c'est ainsi, vu que la procedure et les différents formulaires "instancient" des objets(datatable) différent. tout se passe comme si ces objets (différent normalement) pointent sur le même cache.

[Graffito]

Bcp de datagridview

Dans ce cas, c'est très probablement le remplissage des datagridview au moment ou les "binde" qui prend l'essentiel du temps.

Si tu es en Framework 2.0, tu verras une amélioration avec le 3.5