ODBCDOTNET : EXTRAIRE DES REQUETES ODBC DANS UN TABLEAU DE TABLEAUX DE STRING
Afyn
Messages postés
608
Date d'inscription
samedi 3 août 2002
Statut
Membre
Dernière intervention
22 décembre 2016
-
19 nov. 2005 à 14:01
cs_Patrice99 Messages postés 1221 Date d'inscription jeudi 23 août 2001 Statut Membre Dernière intervention 9 septembre 2018 - 11 déc. 2011 à 11:32
cs_Patrice99 Messages postés 1221 Date d'inscription jeudi 23 août 2001 Statut Membre Dernière intervention 9 septembre 2018 - 11 déc. 2011 à 11:32
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/34701-odbcdotnet-extraire-des-requetes-odbc-dans-un-tableau-de-tableaux-de-string
https://codes-sources.commentcamarche.net/source/34701-odbcdotnet-extraire-des-requetes-odbc-dans-un-tableau-de-tableaux-de-string
11 déc. 2011 à 11:32
1 févr. 2008 à 00:32
http://brunews.com/benchs/trieur.html
Que chacun n'hésite pas à améliorer les codes et à les proposer pour publication.
16 janv. 2008 à 22:53
15 janv. 2008 à 17:10
http://brunews.com/benchs/index.htm
15 janv. 2008 à 16:57
15 janv. 2008 à 15:10
14 janv. 2008 à 01:18
Ouvert à tous langages, plus il y aura de modules différents essayés et plus réalistes seront ces benchs.
Les envois de tests devront se faire en ZIP contenant exe et code source.
Les pseudo des meilleurs par langage seront publiés et les codes ultérieurement afin de ne pas influencer sur les méthodes propres à chaque langage.
Objets de ces benchs:
- Traitements sur fichiers.
- Manipulation de chaines.
- Tri de données.
Trieur.exe est le module à faire et qui sera mesuré en performances et fiabilité.
Pour commencer, télécharger http://brunews.com/Utils.zip qui contient 3 EXEs:
- IdxSrc.exe vous fabriquera Idx.txt et Src.txt contenant chacun 1 million de lignes de données.
- Bench.exe avec lequel on lance Trieur.exe que vous produirez afin d'en mesurer les perfs. Ainsi aisé de mesurer l'évolution ou non de son code.
- Trieur.exe que j'ai fait, à placer dans le même dossier que les 2 txt. Lancez le avec Bench.exe, il vous donnera Tri.txt qui vous servira de référence pour savoir si vous produisez les données attendues, il vous donnera aussi un début de comparatif avec votre propre code.
CAHIER DES CHARGES DE Trieur.exe
Il prend 2 fichiers en entrée dans son dossier, Src.txt et Idx.txt, Src contenant les items à rechercher dans Idx.
Il y aura donc: 1 000 000 * 1 000 000 de comparaisons possible maxi.
Trieur.exe NE DOIT ABSOLUMENT PAS charger Idx.txt au complet en mémoire, il doit être capable de gérer un Idx.txt allant jusqu'à 3 Go. Une utilisation de 5000 Ko de ressources mémoire maxi est requise.
Src.txt contient ces lignes: REF(20) + SITE(4) + TYP(2)
Idx.txt contient ces lignes: SITE(4) + REF(20) + ID(8) + FIN(2)
TRES IMPORTANT: Idx est trié en ASCII, ORDER BY: SITE,REF.
Le but est de lire chaque ligne de Src et d'aller chercher si l'enreg existe dans Idx selon la contrainte: Src.Site Idx.Site AND Src.Ref Idx.Ref
Si enreg trouvé, on produit dans Tri.txt une ligne: Idx.ID(8) + Src.SITE(4) + Src.TYP(2), soit 14 octets au total sans aucun séparateur, juste le saut de ligne de type CRLF à ajouter.
A vos claviers et bon code.
BruNews
monpseudo=brunews
Envois des zip: monpseudoAROBASEmonpseudoPOINTcom
12 janv. 2008 à 11:14
http://patrice.dargenton.free.fr/tmp/TestPerf.zip
1700 Ticks en moyenne pour retrouver un ID existant
1000 Ticks en moyenne pour vérifier qu'une clé est inexistante
9 janv. 2008 à 23:27
9 janv. 2008 à 18:42
9 janv. 2008 à 15:36
C'est extrêmement lourd! + Les bugs IE-FF + serveur + ...
En plus les fondateurs de ce site soutiennent l'open source mais ils ne l'utilisent pas :s
C'est l'attachement de Nix à VB6 ou quoi? :p
9 janv. 2008 à 13:48
Avec Vista et IE7 nickel, toujours les mystères du web...
J'en parle avec Nix.
9 janv. 2008 à 13:29
Par ailleurs je n'ai constaté aucune amélioration avec la dernière version de BruNews, bizarre !
Au fait je ne peux plus poster de commentaire avec IE6, ya qu'avec FireFox que ça marche !
9 janv. 2008 à 12:00
Sera peut-être publié pour tous (avec les différentes versions et langages) si arnotic trouve le temps de le WEBer (je n'entends rien aux weberies).
Les benchs ne sont pas finis, faudra ensuite parser par ligne un fichier source et appeler en rafale bnFindIdx() et écrire le résultat.
Je bosse actuellement sur ce projet donc patience mais sois tranquille que je tiens vraiment à avoir des pages de références avec des benchs en vraie situation. Les comparaisons ne valent que si c'est mesurable par tous et qu'on n'est pas partie prenante.
9 janv. 2008 à 11:41
8 janv. 2008 à 10:30
Les tests chez moi donnent :
- 270 ticks! dès la première exécution (le PerfCounter est stable)
- 3,9 Mo (invariable!) mémoire utilisée
8 janv. 2008 à 00:14
réduction drastique des temps grace à 1 seule lecture de 4000 lignes maxi, nouveau format d'indexation permet de pointer direct sur le bon bloc et donc plus de bouclage disque.
C'est couplé à la binarisation vue plus haut.
7 janv. 2008 à 20:24
La 1ere fois il faut charger le(s) bloc(s) de fichier, ensuite le cache du disque le sert direct.
Je tente en ce moment une indexation des REF par bloc site pour ne plus boucler du tout sur le fichier. Si OK je mettrai en tests.
Code final sera dispo pour ceux qui auront participé aux benchs de la version prod.
7 janv. 2008 à 19:46
- 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?
6 janv. 2008 à 17:17
Juste l'exe et le fichier de données.
Nouvelle méthode sur même type d'algo, important benef par rapport au tout début.
C'est version imitant prod, pas de chargement complet du fichier.
5 janv. 2008 à 21:04
http://rafb.net/p/I3Vcxz44.html
5 janv. 2008 à 20:56
5 janv. 2008 à 17:20
java malheureusement non testable.
5 janv. 2008 à 16:59
Avec Hashtable :
- Des temps quasi Null!(pure des cas 16 ticks!) pour java
- en C : 8 ticks
- en VB.net : 443 ticks
SANS Hashtable :
- En VB.net (non disponible pour tester)
- En Java : 108 ticks (méthode parser ligne par ligne)
- En C : première exécution 1103 ticks, puis entre 456-600 ticks
=>VB vs Java : c'est déjà le 1/4 sans parler de l'utilisation de Hashtable et la mémoire consommée (en VB.net) (incomparable) :p
=>C vs Java : C'est comparable! :)
5 janv. 2008 à 09:38
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.
4 janv. 2008 à 16:14
4 janv. 2008 à 16:06
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
4 janv. 2008 à 16:02
Effectivement COQ : si je stoppe le timer avant de faire la màj GUI, je retombe aussi à un résultat absolument équivalent.
Conclusion : BruNews est capable de programmer une hashtable à la main apparemment aussi rapide (il faudrait tester d'autres valeurs au hasard, et aussi avec la hashtable). L'avantage de la version de BruNews est qu'elle n'alloue pas les 20 méga en RAM : bien sûr dans la version DotNet, tant qu'on doit interroger la hashtable, on ne peut pas la libérer. Je vais poursuivre qq tests...
4 janv. 2008 à 15:58
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.
4 janv. 2008 à 15:13
4 janv. 2008 à 15:01
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()
4 janv. 2008 à 14:06
Je rappelle que n'ira pas en prod mais on aura au moins une base de benchs:
http://brunews.com/FindIdxFULL.zip
Testé ici sur bixeon et 4 Go ram:
en recherchant ligne 45172
.NET : 216
C : 7
ratio de quasi 31 fois plus lent.
4 janv. 2008 à 12:41
4 janv. 2008 à 11:44
Si le fait de laisser le GC décider par lui même de la nécessité ou non de devoir passer du temps à libérer de la mémoire vous choque, il faut effectivement laisser tomber .NET/Java et rester en natif.
Et si vous voulez réellement comparer, restez dans les contraintes énoncées par Bruno, ça n'a aucun intérêt sinon.
4 janv. 2008 à 11:21
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
4 janv. 2008 à 10:18
4 janv. 2008 à 10:16
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é.
4 janv. 2008 à 10:02
4 janv. 2008 à 09:55
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
3 janv. 2008 à 17:45
3 janv. 2008 à 17:40
Bon! le soir je mate le code un peu :-)
Merci encore BruNews!
PS : C'est un très propre code!
3 janv. 2008 à 15:19
davidauche > la réalité est tétue, la rapididté tant que ça ne doit rien faire.
3 janv. 2008 à 14:39
(Je déconne hein! ;-))
3 janv. 2008 à 14:19
3 janv. 2008 à 13:48
3 janv. 2008 à 13:43
Merci BruNews!
3 janv. 2008 à 10:44
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).
2 janv. 2008 à 19:48
http://brunews.com/FindIdxPROJ.zip
mais bof, il n'y aura là rien de pensé en .NET (classes, gestion exeptions, etc..).
2 janv. 2008 à 09:59
Voici comment j'ai converti dbx2txt en DotNet pour info :
http://patrice.dargenton.free.fr/CodesSources/Dbx2Txt.vbproj.html#41
31 déc. 2007 à 17:54
Je lis le fichier par passes de 4000 enregs à la fois en mémoire pour rechercher l'item.
Libre à vous de déterminer ce qui est le plus performant avec le framework en taille mémoire mais ne pas dépasser 4000 car en prod j'ai besoin de beaucoup d'autres buffers et ça doit tourner à tout coup.
Patrice, ce simple exemple me semble un bon début de benchmark, il regroupe pas mal de choses employées habituellement. On pourrait fort bien si tu le veux étendre ultérieurement les benchs avec d'autres tests (recherche de mini et maxi sur différents types numériques, etc.) et publier l'ensemble quand on aura une batterie assez étendue.
31 déc. 2007 à 09:59
Mais pour un vrai benchmark il faut tester pas mal de situations différentes et représentatives.
30 déc. 2007 à 11:55
On va faire un petit test nous mêmes, la presse et moi...
http://brunews.com/FindIdx.zip
Il y a exe et un txt dans le zip.
Ouvre txt dans notepad, ensuite lance exe.
Les lignes du exe contiennent:
SITE(4 char) + REF(20 char) + ID(8 char) + cadrage(2 char)
total = 36 avec le CRLF
Grace au txt ouvert, tu copies et colles SITE et REF dans la dialog, bouton OK te donne ID associé ou NIET si pas trouvé.
Pour ce faire, prévoir une fonction "int bnFindIdx()" retournant 1 si trouvé sinon 0, si 1 on remplit une chaine des 8 char de ID.
Zone PerfCounter est mesure haute précision obtenue:
QueryPerformanceCounter((LARGE_INTEGER*) &deb);
retour = bnFindIdx();
QueryPerformanceCounter((LARGE_INTEGER*) &fin);
counter pris juste avant l'appel et illico derrière. On affiche fin - deb.
Précision: Interdit d'allouer une string avec tout le fichier, le txt est petit ici pour tests mais dans la réalité il contient la plupart du temps + d'1 million d'enregs. En clair, lecture séquentielle obligatoire à chaque appel de la fonction.
Je suis curieux de savoir ce que donnera la comparaison.
30 déc. 2007 à 10:37
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.
29 déc. 2007 à 11:34
Sql Server, Office, Visual Studio (2008 !!!), etc, etc. absolument tout est en natif, bizarre que l'éditeur de .net ne pense pas à l'utiliser.
Soyons sérieux, on n'a jamais rien produit en interprété, c'est pas demain la veille que ça changera.
29 déc. 2007 à 10:53
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.
27 déc. 2007 à 14:18
Donc VB(plus généralement .NET) n'est pas fait pour ces applications et pour l'ETL surtout! Imagine la base de votre client s'enrichir à 1 million d'article, vous allez lui dire quoi?
Sinon pour orienter un peu les futurs programmeurs des applications d'ETL, faut vraiment oublier le .Net et le VB6. Il y a des autres langages plus compétences pour ce genre des applications : C++, Perl et Java.
Java est plus facile et souplesse mais un peu moins rapide que Perl et C++. En passant en native en Java on peut avoir les mêmes complexités (+/-) que les deux autres.
Thx :-)
25 déc. 2007 à 12:29
24 déc. 2007 à 11:45
Pourrais-tu nous communiquer les résultats des calculs de la complexité (temps/ressources) de ce programme? (par exemple un traitement sur une base de donnée d'un million élément).
Merci d'avance.
25 nov. 2007 à 11:19
3 janv. 2007 à 08:53
Pour celle-ci, un ODBCDotNet.sln "Envoyer vers" "Microsoft Visual Basic 2005 Express Edition" fait l'affaire.
2 janv. 2007 à 17:35
(Meilleurs voeux)
Afyn - Navedac
16 avril 2006 à 12:07
20 nov. 2005 à 11:03
20 nov. 2005 à 09:28
Par contre ma source fonctionne avec des dizaines de sources ODBC variées, du moment qu'il existe un pilote ODBC pour Windows, toute base de données peut être interrogée ainsi, même des fichiers textes ou csv !
19 nov. 2005 à 15:55
http://www.cppfrance.com/code.aspx?ID=27746
19 nov. 2005 à 14:59
ODBC pur via les API : Jamais entendu parler ! tu as un exemple ? cela m'étonnerait que cela soit aussi général (pour Windows) qu'ODBC via ADO.
19 nov. 2005 à 14:01
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