[C#] Probléme de performance avec IsDbNull

J'ai fait un programme qui transfert les données d'un fichier texte via un ODBCDataReader dans une table.
J'ai trouvé les performances un peu faible. J'ai donc utilisé le profiler qui m'indique que 50% du temps d'exécution de ma méthode est occupée par l'exécution de la méthode IsDbNull.
Je dois évidement tester IsDbNull pour chaque champ de chaque enregistrement.
Cette méthode à l'air particulièrement lente. Est-il possible de réaliser le test autrement.

Actuellement je fait:

Citation:

---

if(!data.IsDBNull(1))
{
field1 = data.GetString(1);
}

---

Il semble bien que GetString fonctionne rapidement alors qu'il s'effectue dans 99.99% des cas.

Sur quel SGBD?

tu es obligé d'utiliser ODBC ?

Oui, il s'agit de fichier Text de longueur fixe. Je pourrais lire le fichier dans un flux mais l'interêt ici est que je peux utiliser une définition externe (schema.ini). Car si les champs sont toujours les mêmes, selon l'origine de mon fichier les positions des champs peuvent varier

Ah je n'avais pas vu tu le dis que c'est pour un fichier Texte dans ton premier message.

A ta place j'esserai d'éviter l'ODBC quand même. Si tu as l'ordre des colonnes à chaque fichier reçu (dans l'entête par exple) tu peux toujours te faire un algo qui lit bien le fichier.

Sinon pour l'odbc sur du text, est il vraiment nécéssaire de tester si un enrgistrement peut être null? Si l'enregistrement est vide, as tu une chaine vide ou dbnull? C'est facile à tester ça non ?

Comme abel, je pense que c'est le IsDbNull du reader du provider ODBC qui patinne...

ODBC n'a jamais été une référence en terme de perfs :?

IsDbNull doit être testé car assez bizarement si le champ contient uniquement des espace, l'ODBC le considère comme null et provoque une exception sut GetString. Il ne me reste donc plus qu'a tout réécrire. :(

Citation:

---

Envoyé par jab

Citation:

---

if(!data.IsDBNull(1))
{
field1 = data.GetString(1);
}

---

---

Et si tu essayes

Code:

---

1 2 3

object toto = data[1]; if ( !DBNull.Value.Equals( toto ) ) field1 = Convert.ToString( toto );

---

?

Plus rien n'est demandé au reader, à part la valeur 'brute'. Si le problème de perfs vient du reader, la différence devrait se voir avec ça.

J'avais pensé à la même chose ou prseque.

Code:

---

1 2 3 4 5 6

o = data.GetValue(nChamp); if ( !DBNull.Value.Equals(o) ) { cS1 = (string)o; }

---

J'ai fait les tes mais pas de différence significative.

Je suis occupé à faire des tests pour trouver la réponse. J'ai mis tout les champs en commentaire et tout les traitement de contrôle sur les données aussi pour qu'il reste un minimum. Les choses se présente comme ceci (en gros)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

while (data.Read()) { if (data.IsDBNull(38)) { ... }else{ o = data.GetValue(1); if (!DBNull.Value.Equals(o)) { field1 = (string)o; } } }

---

Le programme met 120 secondes.

Si je le change comme ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

while (data.Read()) { o = data.GetValue(38); if (false) { ... }else{ o = data.GetValue(1); if (!DBNull.Value.Equals(o)) { field1 = (string)o; } } }

---

Il met approximativement le même temps et c'est également le même temps si je fais

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

while (data.Read()) { if (data.IsDBNull(38)) { ... }else{ if (data.IsDBNull(1)) { field1 = data.GetString(1); } } }

---

Ce qui tend à dire que si le profiler donne 50% du temps à IsDBNull, le fait de l'enlever reporte le traitement de lecture sur l'instruction suivante et le problème reste entier. :(

Bizarement, si je fais

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

while (data.Read()) { if (false) { ... }else{ if (data.IsDBNull(1)) { field1 = data.GetString(1); } } }

---

Je passe de 120 sec à 35 sec ! alors que je ai enlevé moins de la moitié du traitement. :?

IsDbNull n'est en définitive pas en cause. C'est la première méthode sur un champ qui provoque sa lecture. Donc si on fait un IsDbNull, il semble lent en regard du GetString. Mais si on retire le IsDbNull, c'est le GetString qui du coup est plus lent. :(

J'ai pu gagner 25% de perf en utilisant le provider Jet.OLEDB qui permet l'accès aux fichiers textes aussi.

Merci pour votre aide.