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

Messages postés
613
Date d'inscription
samedi 3 août 2002
Statut
Membre
Dernière intervention
22 décembre 2016
- - Dernière réponse : cs_Patrice99
Messages postés
1222
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

Afyn
Messages postés
613
Date d'inscription
samedi 3 août 2002
Statut
Membre
Dernière intervention
22 décembre 2016
-
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
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
ArrayList : Oui ça serait pas mal, cela éviterait le ReDim Preserve, je n'arrive pas encore à oublier totalement VB6 :-)

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.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
ODBC CONNEXION MDB ET CREATION TABLE (WIN32)
http://www.cppfrance.com/code.aspx?ID=27746
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
BruNews : Ok, il s'agit d'une connexion bas niveau via les API (notamment SQLExecDirect), et l'exemple fonctionne avec Access, mais je ne pense pas que cela puisse fonctionner avec d'autres sources ODBC (peut-être SQL Serveur, mais cela me semble risqué...). Il y a même un bout de code très bas niveau en assembleur ! (heureusement que c'est seulement pour copier une chaîne de caractères, mon exemple en assembleur, c'était pour plaisanter :-)
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 !
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
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.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
Nouvelle version : on peut maintenant remplir très rapidement un fichier Excel sans ouvrir Excel ! (il faut juste qu'il y ait un entete pour chaque colonne)
Afyn
Messages postés
613
Date d'inscription
samedi 3 août 2002
Statut
Membre
Dernière intervention
22 décembre 2016
-
T'as pas une version VB 2005 espress pour la nouvelle année ?

(Meilleurs voeux)

Afyn - Navedac
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
A chaque fois que je poste ou met à jour une source, je teste en VB2005 express pour avoir si possible aucun warning, mais cette année, mes voeux sont de migrer toutes mes applis utilisées professionnellement en DotNet2/VB2005. En tout cas mon prochain développement sera en VB2005 (pour le moment j'évite pour ne pas avoir 2 versions à maintenir, mais c'est vrais que je vais bientôt abandonner VB2003 et VB6, comme ça je pourrais mettre le compilo gratuit sur un portable pour pouvoir faire des corrections sur site).
Pour celle-ci, un ODBCDotNet.sln "Envoyer vers" "Microsoft Visual Basic 2005 Express Edition" fait l'affaire.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
Nouvelle version, en DN2 cette fois :-)
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
ETL en VB! c'est étrange pour moi :-)
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.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
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 :-)
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
Merci Patrice! pour ces informations.
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 :-)
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
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.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
Dans la presse, quand c'est écrit blanc on croit noir et vice versa, ça évite toute désillusion ultérieure. La 1ere question à se poser est de savoir pourquoi on l'écrit et qui paie pour le publier.
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.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
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.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
Les subtilités dans les mots ne changent rien à l'affaire.

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.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
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.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
Autre précision:
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.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
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
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
voila
http://brunews.com/FindIdxPROJ.zip

mais bof, il n'y aura là rien de pensé en .NET (classes, gestion exeptions, etc..).
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
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).
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
Patrice SVP on attend les résultats de .Net! (ça m'intéresse beaucoup). Peu importe la technique utilisée, l'important qu'elle soit optimisée au maxi.

Merci BruNews!
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
PS BruNews : votre lien ne fonctionne pas http://brunews.com/FindIdxPROJ.zip
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
J'imagine que cela peut intéresser oui, mais cela représente quand même du boulot, et je préfère éviter de perdre du temps s'il s'agit d'un faux problème. Toutefois, le lien de BruNews est valide, et à priori ce boulot ne devrait pas présenter trop de difficulté, mais yen a pour plusieurs heures tout de même : j'avais prévu d'autres urgences pendant mes quelques jours de vacances (par exemple poursuivre mes migrations DN2).
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
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! ;-))
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
J'ai remis le projet vu que ça semble intéresser du monde.

davidauche > la réalité est tétue, la rapididté tant que ça ne doit rien faire.
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
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!
cs_coq
Messages postés
6352
Date d'inscription
samedi 1 juin 2002
Statut
Modérateur
Dernière intervention
2 août 2014
75 -
davidauche => Sur 20 chars la ref, rajoute les espaces derrière.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
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
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
BruNews, si tu penses que j'ai triché, alors explique moi pourquoi toi tu ne peux pas faire pareil (car je n'ai toujours pas compris pourquoi tu ne pouvais allouer plus de mémoire, car en DotNet, cela ne pose pas tant de pb).
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
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é.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
Pour info, DotNet comme tout autre prog n'a d'autre voie que VirtualAlloc pour la mémoire, il n'y a pas de miracle.
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
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
cs_coq
Messages postés
6352
Date d'inscription
samedi 1 juin 2002
Statut
Modérateur
Dernière intervention
2 août 2014
75 -
Mais pourquoi forcer le GC ? Laissez le faire son boulot tranquille !
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.
cs_Arnotic
Messages postés
936
Date d'inscription
dimanche 1 avril 2001
Statut
Modérateur
Dernière intervention
9 janvier 2012
-
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.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
OK j'ai fait la meme version qu'en .NET, fichier full chargé.
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.
cs_coq
Messages postés
6352
Date d'inscription
samedi 1 juin 2002
Statut
Modérateur
Dernière intervention
2 août 2014
75 -
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()
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
SVP, une bonne volonté pour refournir le zip avec maj, je n'ai pas VB d'installé.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
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.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
Effectivement BruNews : ta nouvelle version est passée de 400 000 ticks à moins de 10000 (5000 même parfois), impressionnant !

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...
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
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
cs_coq
Messages postés
6352
Date d'inscription
samedi 1 juin 2002
Statut
Modérateur
Dernière intervention
2 août 2014
75 -
Oui mais quoiqu'il arrive en situation réelle la hashtable ne sera pas utilisable, tu devrais passer directement aux tests réels.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
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.
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
J'ai codé les deux versions en java : http://www.megafileupload.com/en/file/34194/FindIdxJava-zip.html

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! :)
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
Aurais-tu le code java des 2 versions dispo ? m'intéresserait d'y jeter un oeil.
java malheureusement non testable.
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
dsl J'ai oublié de noter qu'il faut mettre le fichier des données dans C:\
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
http://brunews.com/FindIdx.zip

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.
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
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?
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
La recherche sur les 20 octets de REF se fait en 5 DWORDs et traités direct en mode binaire. On a ainsi accès aux comparaisons <, == ou > en 1 cycle.
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.
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
http://brunews.com/FindIdxFAST.zip
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.
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
Excellent BruNews!!!
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
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
@BruNews : à quand les sources de ta dernière version!?
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
no problem, sera distribué aux participants comme prévu.
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.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
Je vais moi aussi faire un test en rafale : je vais piocher par exemple 100 entrées au hasard (parmi les valides) et calculer la moyenne des ticks par référence. Il faudrait peut etre aussi ajouter des references qui n'existent pas pour comparer les perf. dans ce cas de figure aussi, car je crois que la hashtable est très performante aussi dans ce cas.
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 !
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
Je sais pour IE6, un vrai problème que nos webistes ont du mal à régler. Moi c'est l'affichage des souces qui merdoie quand je suis au bureau sur IE6.
Avec Vista et IE7 nickel, toujours les mystères du web...
J'en parle avec Nix.
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
Ce qui me fait mal au coeur! cet attachement à l'Asp!
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
cs_coq
Messages postés
6352
Date d'inscription
samedi 1 juin 2002
Statut
Modérateur
Dernière intervention
2 août 2014
75 -
CS n'est pas basé sur de l'ASP3 mais de l'ASP.NET
cs_Arnotic
Messages postés
936
Date d'inscription
dimanche 1 avril 2001
Statut
Modérateur
Dernière intervention
9 janvier 2012
-
On fera tout ce qui est évoqué plus haut. Sera trés intéressant de publier des benchs.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
Nouvelle version VB.Net : Tests en rafale :
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
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
BENCHS sur Trieur.exe, Window exclusivement (Win2000 ou sup).

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
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
davidauche
Messages postés
150
Date d'inscription
jeudi 20 mars 2003
Statut
Membre
Dernière intervention
8 janvier 2008
-
Le lien est cassé :(
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
Si FF ajouter nom de page, devrait aller:
http://brunews.com/benchs/index.htm
cs_Arnotic
Messages postés
936
Date d'inscription
dimanche 1 avril 2001
Statut
Modérateur
Dernière intervention
9 janvier 2012
-
Il manque le "l" à "html" : http://brunews.com/benchs/index.html
BruNews
Messages postés
21042
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
16 -
Les premiers résultats ici:
http://brunews.com/benchs/trieur.html
Que chacun n'hésite pas à améliorer les codes et à les proposer pour publication.
cs_Patrice99
Messages postés
1222
Date d'inscription
jeudi 23 août 2001
Statut
Membre
Dernière intervention
9 septembre 2018
-
Version 1.12 : ODBC en 64 bits -> mode 32 bits forcé via PlatformTarget=x86