ODBCDOTNET : EXTRAIRE DES REQUETES ODBC DANS UN TABLEAU DE TABLEAUX DE STRING

Commentaire de Afyn le 19/11/2005 14:01:37

Salut ... bravo
Peut être remplacer le tableau par un ArrayList ?
Et utiliser For each ?
Sinon, c'est pas vraiment de l'ODBC pur ... puisque tu utilises ADO (environ 50% plus lent que les API en direct ...)
Bonne suite ...

Afyn - Navedac

Commentaire de BruNews le 19/11/2005 15:55:51 administrateur CS

ODBC CONNEXION MDB ET CREATION TABLE (WIN32)
http://www.cppfrance.com/code.aspx?ID=27746

Commentaire de BruNews le 20/11/2005 11:03:17 administrateur CS

Comme tout le reste, c'est plus long à coder en natif plutot qu'en VB + ADO mais tout se fait. Il faudrait générer la chaine de connexion à l'exécution selon la cible choisie par l'utilisateur, des logiciels commerciaux le font.

Commentaire de Afyn le 02/01/2007 17:35:14

T'as pas une version VB 2005 espress pour la nouvelle année ?

(Meilleurs voeux)

Afyn - Navedac

Commentaire de Patrice99 le 25/11/2007 11:19:15

Nouvelle version, en DN2 cette fois :-)

Commentaire de Patrice99 le 25/12/2007 12:29:01

Le fait que cela soit en VB.Net ne change strictement rien (par rapport à C# par exemple). Par contre, le fait de faire des requêtes via ODBC est assez lent, beaucoup plus lent que via des pilotes natifs, c'est sûr, cela ne se discute pas. Par contre, c'est beaucoup plus générique (pas besoin de changer de code selon le PGI du client chez qui tu installes ton logiciel), juste à changer légèrement la syntaxe des requêtes éventuellement. Par exemple un client qui utilise une base distante via TSE avec 5000 articles, il faut 20 minutes pour extraire les stocks et les ventes du mois, assez long donc. Par contre en écriture, c'est très très long, seul un pilote natif peut fonctionner à mon avis. Mais l'idée de faire des outils en VB de pilotage du niveau de stock chez des clients quelque soit leur PGI, c'est plutôt cool, car pas besoin d'être bac+10 pour programmer en VB :-)

Commentaire de Patrice99 le 29/12/2007 10:53:26

En fait, faire de l'ETL via ODBC, ça passe encore s'il n'y a pas beaucoup d'article, en effet.
S'il y a beaucoup de données, il faudra donc abandonner ODBC et attaquer directement le PGI via des pilotes natifs.
Maintenant, comme on est sur VBFrance, bien sûr que je ne suis pas d'accord avec toi : VB.Net est à mon avis le langage le plus productif qui existe, et à lire la presse informatique, il semblerait que VB.Net finisse par l'emporter sur Java et C#, C++ étant réservé à quelques niches.

Commentaire de Patrice99 le 30/12/2007 10:37:10

Brunews : Hum, je crois que j'ai déjà essayé de t'expliquer que l'interprété ce n'est pas tout à fait la même chose que la compilation à la volée : le code pseudo-assembleur est recompilé avant sa première exécution en fonction du processeur utilisé, de sorte que la différence de performance n'est pas si grande que ça : on pourra d'ailleurs toujours améliorer le compilateur à la volée (comme en java).

Pour ce qui est de la presse, mon impression provient des projections d'embauche en fonction des langages les plus demandés (01Informatique en Novembre 2007) : Java : 41%, VB.Net : 31%, C# : 15%

Pour ce qui est des benchmarks, c'est pas évident de trouver des études sérieuses, mais cette page montre qu'il n'y a pas de différence entre C# et C++, et peu entre C++ et C (malheureusement la page d'explication "Scorecard page" n'est plus disponible) :
http://dada.perl.it/shootout/craps.html
http://dada.perl.it/shootout/index.html
Si tu trouves un benchmark plus intéressant je suis preneur.

Commentaire de Patrice99 le 31/12/2007 09:59:24

Tu penses pas sérieusement à faire un vrai benchmark avec un test aussi limité ? Cependant je vais quand même y jeter un oeil pour voir...
Mais pour un vrai benchmark il faut tester pas mal de situations différentes et représentatives.

Commentaire de Patrice99 le 02/01/2008 09:59:52

Depuis que j'ai converti la source www.leapsecond.com/tools/dbx2txt.c en VB.Net, je pense pouvoir normalement convertir ton exemple : pourquoi est-ce que tu ne me donnes pas ta source en C ou C++ pour que je fasse exactement les mêmes instructions en DotNet ? ça serait assez intéressant je trouve, non ?

Voici comment j'ai converti dbx2txt en DotNet pour info :
http://patrice.dargenton.free.fr/CodesSources/Dbx2Txt.vbproj.html#41

Commentaire de Patrice99 le 03/01/2008 10:44:37

Effectivement en DotNet bien sûr on ne ferait pas comme ça : on ferait une hashtable avec pour clé une chaîne regroupant l'ensemble des clés requises, c'est à dire ici SITE + REF : ht(Site & Ref) --> ID de la façon suivante en une ligne de code :
If Not ht.ContainsKey(Site & Ref) Then ht.Add(Site & Ref, ID) Else ID = DirectCast(ht(Site & Ref), Long)
C'est impensable de reprogrammer une routine de dichotomie pour rechercher des valeurs !
Je ne comprend pas ta problématique : si tu as besoin de perf alors il faut charger l'index en RAM, tu dis que tu ne peut pas car tu utilises déjà d'autres buffers ? tu as un problème de contrainte particulière qui t'oblige à faire du bas niveau ? ou bien c'est juste par habitude ?
Si t'as vraiment beaucoup de données et que ça loge plus en RAM, alors de toute évidence il faut utiliser un SGBD (et d'ailleurs on peut même remettre le SGBD en RAM, c'est ce que fait Google je crois).
Je ne voie pas en quoi ce test serait représentatif d'un benchmark (d'ailleurs ton idée d'en commencer un est certes louable, mais c'est un job d'une thèse entière, bizarre qu'on ne trouve pas de telle étude facilement d'ailleurs, peut être que ça ferait grincer trop de dents... de même qu'il n'existe pas d'étude comparative des religions :-).

2 choses à ajouter :
Java 9 à 22% et DotNet 54% à 79% : Environnement de développement privilégié par type d'entreprise, tout secteur confondu (public et privé, pour 1850 entreprises interrogées de toutes tailles, d'après une étude Info-Tech Research Group) : source = 01 Informatique n° 1930 du 20 décembre 2007 page 26 (il faut comprendre que le reste des langages = niche).

SQL Serveur 2005 : possibilité de programmer des types : langage : DotNet (même si le moteur lui même n'est pas en DotNet, mais lorsque les hyperviseurs se généraliseront, alors le tout DotNet pourra décoller).

Commentaire de davidauche le 03/01/2008 13:48:58

PS BruNews : votre lien ne fonctionne pas http://brunews.com/FindIdxPROJ.zip

Commentaire de davidauche le 03/01/2008 14:39:11

Bah justement, ils disent que VB.Net c'est la facilité, la productivité et la rapidité! tu viens de les contredire :-p

(Je déconne hein! ;-))

Commentaire de davidauche le 03/01/2008 17:40:51

Est-t-il normal que le programme ne marche pas? quand je lance Find avec URL "ULIS" et REF "52144" rien se passe.
Bon! le soir je mate le code un peu :-)

Merci encore BruNews!
PS : C'est un très propre code!

Commentaire de Patrice99 le 04/01/2008 09:55:14

Voici ma source, elle est plus rapide et plus stable en performance : 200000 ticks environ

http://patrice.dargenton.free.fr/tmp/TestPerf.zip

Public Class Form1

Private m_ht As New Hashtable

Private Sub Form1_Load(ByVal sender As Object, ByVal e As EventArgs) _
    Handles Me.Load

    Dim sCheminIndexes$ = Application.StartupPath & "\Indexes.txt"
    Using fs As New IO.FileStream(sCheminIndexes, IO.FileMode.Open, IO.FileAccess.Read)
    Using sr As New IO.StreamReader(fs)
    Do
        Dim sLigne$ = sr.ReadLine()
        If sLigne Is Nothing Then Exit Do
        Dim sSite$ = sLigne.Substring(0, 4)
        Dim sRef$ = sLigne.Substring(4, 20)
        Dim sCle$ = sSite & sRef
        Dim sId$ = sLigne.Substring(24, 8)
        If Not Me.m_ht.ContainsKey(sCle) Then Me.m_ht.Add(sCle, sId)
    Loop While True
    End Using
    End Using

End Sub

Private Sub cmdChercher_Click(ByVal sender As Object, ByVal e As EventArgs) _
    Handles cmdChercher.Click

    Dim sSite$ = Me.tbSite.Text
    Dim sRef$ = Me.tbRef.Text
    Dim sCle$ = sSite & sRef
    Me.tbIdx.Text = "(non trouvé)"
    ' http://plasserre.developpez.com/v7-4.htm = Kernel32.QueryPerformanceCounter
    Dim Stopwatch As Diagnostics.Stopwatch = Diagnostics.Stopwatch.StartNew()
    If Me.m_ht.ContainsKey(sCle) Then Me.tbIdx.Text = DirectCast(Me.m_ht(sCle), String)
    Me.tbPerf.Text = Stopwatch.ElapsedTicks.ToString()

End Sub

End Class

Commentaire de BruNews le 04/01/2008 10:16:02 administrateur CS

En prod ceci est impossible.
La fonction bnFindIdx() est dans un projet important avec plusieurs fichiers énormes à traiter, tous ouverts dans lesquels on pioche l'info nécessaire et selon type d'info et autres params on fait telle manip sur les données.
Il ne faut pas songer un instant à tout mettre en ram, le prog doit tourner à tout coup quelle que soit la taille des fichiers. Le genre de traitement que tu proposes ne doit jamais s'envisager autrement que dans des applets de postes cleints, sur un serveur c'est prohibé.

Commentaire de davidauche le 04/01/2008 11:21:04

Bon bon on va pas comparer comme ça Patrice!

Après petit test vite fait :

- Oui Ton programme est plus performant au niveau rapidité mais au niveau ressources!!!
- Il n'est pas stable du tout! pas de libération des ressources! (Faut forcer ton Garbage collector peut être)
- Ton programme utilise 21 640 Ko
+ Or celui de BruNews utilise uniquement 3 860 Ko

Commentaire de Arnotic le 04/01/2008 12:41:34 administrateur CS

En mettant tout le fichier en mémoire j'arrivais à rechercher le bon ID en 21 tick. Alors nettement moins rapide que la version .net qui me donne 1231 tick pour la même chose.

Commentaire de coq le 04/01/2008 15:01:41 administrateur CS

Le code de Patrice mesure le temps d'execution en incluant la mise à jour du GUI, la différence devrait être moins violente avec un code de ce genre, mais restera sans aucun doute plus lente que le C :

Dim Stopwatch As Diagnostics.Stopwatch = Diagnostics.Stopwatch.StartNew()
Dim idx As String
If Me.m_ht.ContainsKey(sCle) Then
    idx = DirectCast(Me.m_ht(sCle), String)
Else
    idx = "NIET"
End If
Stopwatch.Stop()

Me.tbIdx.Text = idx
Me.tbPerf.Text = Stopwatch.ElapsedTicks.ToString()

Commentaire de BruNews le 04/01/2008 15:58:57 administrateur CS

MERCI à coq pour:
http://brunews.com/TestPerfDOTNET.zip

le ratio n'est plus que de 2 avec le C, pas mal du tout.

Un comparatif sur la 1ere version serait bien maintenant.

Commentaire de Patrice99 le 04/01/2008 16:06:28

Je viens de mettre à jour mon lien :
http://patrice.dargenton.free.fr/tmp/TestPerf.zip

Dim Stopwatch As Diagnostics.Stopwatch = Diagnostics.Stopwatch.StartNew()
If Me.m_ht.ContainsKey(sCle) Then sId = DirectCast(Me.m_ht(sCle), String)
Dim lTicks& = Stopwatch.ElapsedTicks
Me.tbPerf.Text = lTicks.ToString()
Me.tbIdx.Text = sId

Commentaire de Patrice99 le 05/01/2008 09:38:01

Nouvelle version :
http://patrice.dargenton.free.fr/tmp/TestPerf.zip

Notes :
- Le fichier Indexes.txt doit être trié pour la version de BruNews, alors que ce n'est pas nécessaire pour la hashtable ;
- Le code source VB est de niveau débutant alors qu'il est au moins intermédiaire pour la version en C ;
- Hashtable typée = Dictionary : Pas de gain, ni RAM ni perf ! (on évite pourtant un unboxing de Object vers Integer : tester plus de valeurs) ;
- Indexer les sites indépendamment ? (comme la nouvelle version de BruNews) moins de RAM ? tableau de hashtable ? bof ! gains peu probables ;
- RAM allouée : BruNews : 3Mo contre 18,4 Mo pour la version DotNet ;
- Si la taille du fichier Indexes.txt double, alors la RAM allouée via la hashtable doublera aussi (à partir de 10 Mo au minimum) ;
- Reste à faire : moyenne de tests au hasard (car les perf peuvent dépendrent de la position pour la version de BruNews, mais c'est peu probable pour  la version hashtable) ;
- Pour un vrai benchmark, il faudrait programmer le même algo dichotomique en DotNet.

Commentaire de BruNews le 05/01/2008 17:20:04 administrateur CS

Aurais-tu le code java des 2 versions dispo ? m'intéresserait d'y jeter un oeil.
java malheureusement non testable.

Commentaire de davidauche le 05/01/2008 21:04:40

http://rafb.net/p/Xbxd4T31.html
http://rafb.net/p/I3Vcxz44.html

Commentaire de davidauche le 07/01/2008 19:46:17

Chez moi ça passe de :
- 1ère exécution : 6340 (ancienne version) à 4200(la nouvelle)
- 2ème exécution : 3500 (ancienne version) à 2600(la nouvelle)

Je comprends pas pourquoi chaque fois la première exécution est plus lente!

BruNews quelles sont les modifications apportées?