Discussion :

[manu f]

Bonjour,

J'ai une application qui génére un fichier Excel avec vraiment beaucoup de données dedans. Le problème c'est qu'il est super long à générer (plusieurs minutes), j'ai donc isolé la méthode et débogguer pour voir où cela ralentissais précisément et le bout de code qui ralentit c'est lui :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
 
for (int i = 0; i < produitList.Count; i++)
        {
            int total = 0;
            for (int j = 0; j < filialeList.Count; j++)
            {
                ParameterCollection p1 = new ParameterCollection();
                p1.Add("Dossier", "165");
                p1.Add("Produit", produitList[i]);
                p1.Add("Filiale", filialeList[j]);
 
                dt = ***WebTools.SelectAppQuery("SELECT quantite FROM ProduitCommandeDoc WHERE (pk_idDossier = @Dossier) AND (pk_idProduit = @Produit) AND (pk_idSoc = @Filiale)", p1);
                if (dt.Rows.Count > 0)
                {
                    try
                    {
                        int qte = int.Parse(dt.Rows[0]["quantite"].ToString());
                        total += qte;
                    }
                    catch (Exception) { }
                    oExcelSheet.Cells[startRow + j + 1, i + 3] = dt.Rows[0]["quantite"].ToString();
                }
                else
                    oExcelSheet.Cells[startRow + j + 1, i + 3] = "0";
            }
            oExcelSheet.Cells[startRow + filialeList.Count + 1, i + 3] = total.ToString();
        }

Comment puis-je optimiser ce bout de code car jettant un oeil je vois mal comment il peut être codé autrement.

[mermich]

Salut,

au lieu d'effectuer "i*j" fois son select essaie de l'excuter une seule fois, ou "i" fois et de boucler sur les lignes renvoyées

[Immobilis]

Salut

Comment se présente ton fichier? Si il est tabulaire avec un seul onglet utilise un fichier XML.

1. Utilise une procédure stockée
2. Qu'est-ce que "WebTools"?
3. Récupère toutes tes données avant de créer ton fichier Excel

Sinon, tu peux demander à ta boite d'acheter un vrai logiciel de "DataMining" (Business Intelligence).

A+

[manu f]

C'est un fichier excel classique (1 seul onglet est utilisé) qui se présente de cette manière :

Code :

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

1
2
3
4
5
          Produit1   Produit2  Produit3 ...
filiale1
filiale2
filiale3
...

WebTool c'est une libraire développé par ma boite, je l'utilise pour une question partique ça m'évite d'ouvrir une connexion à la BDD, la fermer etc...

Je ne vois pas ce que tu veux dire par utiliser un fichier xml puisque le fichier Excel que je génère, je le propose en téléchargement à l'utilisateur et ce format Excel est imposé.

[Immobilis]

Je ne vois pas ce que tu veux dire par utiliser un fichier xml puisque le fichier Excel que je génère, je le propose en téléchargement à l'utilisateur et ce format Excel est imposé.

Excel ouvre très facilement les fichiers xml "tabulaires".

Sinon, ton code fait plusieurs choses en même temps:

• Récupérer les données,
• réaliser des calculs à la volée,
• Créer un fichier excel et le remplir au fur et à mesure

C'est trop si tu as beaucoup de données.
Faits les étapes les unes après les autres:

• Récupères les données déjà calculées par la base ou bien récupères-en plus et fait le tri avec le code

  Code :

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

  SELECT * FROM ProduitCommandeDoc Where pk_idDossier  in (123, 456, 789)

• Créés la source de données compilée (au format XML)
• Génère ton fichier Excel à partir de cette source

Ainsi, tu sauvegardes les données compilées. Si quelqu'un réclame aussi le fichier Excel tu n'as que la moitié du boulot à faire. Tu peux même juste envoyer le XML.

En créant un fichier XML tu évites de créer un fichier Excel et de remplir les cellules une par une. L'avantage devrait être indéniable sur la consommation des ressources. D'autant que Excel dans ton cas Excel ne te sert que pour ouvrir une source de données. Excel n'a pas la réputation d'être très économe en ressources.

S'agissant de donnée tabulaires tu as plein de solutions:

• Faire faire tout le boulot par un procédure stockée "complexe" (cela évitera les aller et retours entre la base et IIS)
• Faire plusieurs procédures stockées qui remplieront une datatable

J'ai souvent eu des gros fichiers de données à réaliser. Plusieurs procédures stockées + un dataset + des datatables liées m'ont permis de générer des fichiers de plusieurs dizaines de méga en quelques dizaines de secondes.

As-tu lu ce tuto: http://philippe.developpez.com/artic...erexcelaspnet/

A+

[Graffito]

Fais les étapes les unes après les autres

+1

Crées la source de données compilée (au format XML)

Plus facile et plus performant : L'utilisation de fichier .csv (Ascii délimité).

[champomy62]

Salut,

c'est surement à cause de ton " webtool " tu dis ça t'évite d'ouvrir et fermer la connexion. De là je suppose qu'il ouvre et ferme la connexion automatique dès qu'il en a besoin et la ferme aussitôt. En effet tant que i inferieur à la list il va ouvrir et fermer la connexion pour chaque truc si j'ai bien compris !! Et ouvrir une connexion ça prend du temps...

[cinemania]

champomy62 pas forcément... dotnet a des mécanismes un peu particuliers vis à vis des connexions DB, comme la mise en cache et le recyclage des connexions.
en fait quand tu la ferme, elle n'est pas toujours systématiquement fermée aussitôt, et ce même si ton objet SqlConnection a été disposed/finalized... en effet, l'objet n'est qu'une surcouche, mais il y a toute une mécanique qui se cache derrière au niveau de dotnet.

cependant, il serait peut-être plus pertinent d'attaquer la base de données directement selon différents critères...
tout dépend de ces "webtools"...

tout d'abord quel type de base de données, et ensuite quel type de connexion choisie...

certains développeurs, pas tentés, on l'idée saugrenue d'utiliser systématiquement des connecteurs ODBC ou OleDB et ce quelque soit la base située derrière pensant finalement faire un système générique...

dans tous les cas il faut utiliser le connecteur adapté, développé souvent par le concepteur de la base de données, et pour sql server, ils sont nativement inclus dans dotnet, mais bon... forcément c'est plus trop générique... enfin en apparence.

ensuite selon le modèle de développement des webtools si tu n'a pas accès aux sources, tu ne sais pas forcément si ceux ci ne font pas des opérations sur la base, ou des opérations particulières, strictement inutile dans ton cas qui vont te faire perdre un temps précieux.

Ensuite effectivement il faut clairement dissocier ton problème en sous problèmes...
tu récupère l'ensemble des données prétraitées au niveau de la base de donnée, par des procédures stockées.
Si la manipulation de données en question est purement de nature sql et que tout est dans la base pour cela, ce traitement doit être dévolu à la base et non à ton programme.

ensuite ces données tu le mets en forme en XML, en CSV, en ce que tu veux.

ensuite tu sauvegarde le fichier... Et là tout dépend
soit tu part du principe qu'un xml tabulé, ou qu'un csv fera l'affaire excel les ouvrant très bien, et dans ce cas le tour est joué, soit tu part du principe que non il faut impérativement un .XLS
alors tu utilise les COM Interop pour obliger Excel à générer le xls.
mais dans tous les cas, tu part sur des données déjà structurées, mâchées, et donc prête à l'écriture si je puis dire.

[champomy62]

Surement mais j'ai pris mon cas avec access quand j'avais plusieurs operations, j'ouvrais et je fermais dès que j'avais fini le traitement . J'ai fais une ouverture de connexion au début et à la fin du traitement complet et jai gagné 90% de temps...Au détriment de la sécurité mais moi c'était une application monoposte..

[manu f]

Je peux me passer de WebTools mais c'est quelque chose de vraiment stable et optimisé donc je ne pense pas que ça vienne de là.
Par contre j'ai eu une réunion avec quelques client et le directeur, celui-ci veut me montrer des choses sur l'appli. je prie pour qu'il ne clic pas sur le bouton car je sais que ça rame à fond.

Et bizarrement, sur son pc l'excel s'est généré rapidement, j'ai donc interrogé certains utilisateurs et eux non plus n'avaient pas de soucis. Le problème vient donc uniquement de mon poste (ce que je trouve incompréhensible), pour le moment je met donc l'optimisation de ce bout de code en suspend d'autant plus que je suis entrain de voir pour effectuer un upgrade Framework .NET 2 au .NET 4.