Optimisation du temps de traitement, ou mauvaise approche ?

Hello,

je travaille actuellement sur un projet de récupération de données boursieresen passant par une API et vb.net.

Une partie de ces données seront pré-remplies (produit financier, maturité, periode concernée, etc.).

Dans la représentation de cette démarche, le code se compose avec une srie de "briques" élémentaires qui communiquent entre elles (lien mere-fille). Chaque brique est dédiée à une fonction spécifique (ajout de paramètre, enregistrement de valeur, calcul de moyenne, etc.).

J'ai donc une série de briques qui sont créées, reliées et détruites à la volée.

Chaque brique a une "signature" unique, avec seulement les briques feuilles en haut du processus qui sont uniques (briques directement "connectées" au data provider).

mon problème est le temps de traitement global, dont j'ignore s'il provient de mon code ou du data provider en lui meme.

En effet, j'ai pas loin de 400 valeurs à enregistrer toutes les 5 minutes.
Hors, pour le moment ce temps d'enregistrement de 400 vleurs est >>5minutes. Et il est bien entendu que si je réduit à un enregistrement par quart d'heure, plus de soucs, mais granularité trop grosse.

Je cherche donc des pistes d'amélioration. Les multi threads n'ont pas vraiment apporté d'amélioration. :cry:

Je continue ma description, si ca peut aider :aie:

Les communications se font dans le sens montant par des Sub() et dans le sens descendant par des Event déclenchés et catchés par les briques enfants.

Les résultats sont actuellements passés en paramètre dans les évènements.

serait-il pertinnent par exemple d'écrire les dits résultats dans un fichier et de passer le path du dit fichier en paramètre à la place ?

J'avoue êtr eun peu dans la panade, à avoir une problématique qui me dépasse un peu compte tenu de mon inexpérience en VB.net :cry:

ca manque de détails ...

par contre si tu fais 400 requetes, le problème est là, il faut en faire un seule pour gagner du temps (une requete pour 400 valeurs devrait faire quelques millisecondes)
le temps de traitement sur des classes non graphiques est en général insignifiant

OK,

les requetes envoyées à l'API sont composées de 4 éléments :
- le ticker (code qui définit un instrumlent financier)
- une date de début de période
- une date de fin de période
- la fréquence (par tranche de X minutes)

Le problème est qu'autant faire des requêtes me parait aussi être rudimentaire, mais je n'arrive pas à m'expliquer le temps de réponse aussi long de la part du data provider :koi:

Car si je n'arrive pas à diminuer outre mesure mon temps de traitement une fois l'information obtenue, je me pose des questions sur le temps d'obtention de l'information à la source.

J'utilise l'API car me paraissait être la solution, mais je me demande si l'utilisation d'une feuille Excel qui récupère les données en continu, avec un enregistrement à intervalle régulier en dehors du fichier ne serait pas plus "simple" :/

qu'appelles tu data provider ??
de quelle api parles tu ???

sans détails on ne pourra pas t'aider

system.Diagnostics.stopwatch : un chronomètre qui permet de savoir où le code est long

Je passe par CQG, un concurrent de Bloomberg/Reuters et co.
mon data provider est ma plate-forme boursiere.

de quels détails as-tu besoin.

j'ai 10K lignes de code jusqu'à présent...

Hello,

j'ai creusé un peu les sources potentiels de problèmes, et comme j'ai découvert que les event sont synchrones (somme toute logique, mais bon, pas trivial), j'ai posté une nouvelle question à ce sujet ici :
http://www.developpez.net/forums/d12...bliques-place/

L'idée étant de savoir si une disparition de raiseevent au profit de thread avec appel directement de fonctions publiques apporteraient cette amélioration de traitement :)

nous n'avons pas assez d'infos, ca te semble suffisant car tu c'est ton projet mais de l'extérieur on est pas devin !

avant de chercher à optimiser il faudrait déjà savoir où est la perte de temps

si j'ai bien compris tu as une architecture d'instances de classe type arbre, et tu parcours l'arbre jusqu'à chaque extrémité

que fait le méthode appelée sur chaque élément ? une mise à jour des données ? un enregistrement ?

d'où viennent tes données ? base de données ? fichier ? tcp/ip ? dll externe ?
appelle tu la lecture de données une fois pour tout l'arbre ou une fois pour chaque élément ???

as tu mesuré le temps d'acquisition des données ? du traitement ?

bref => ?????????

Hum ok,

J'ai en début de chaîne un outil .exe (feeder sur le dessin).

Les blocs fonctionnels évoqués précédemment sont en gris. Les blocs en haut de l'arbre sont en rose, les data providers. CQG fournit un dll qui sert pour vb.net. Elle permet de manipuler une classe globale qui est utilisée pour faire des requetes et dont on capte les évènements de fin de traitement. On a donc un temps de latence entre le lancement de la query et sa réponse.

J'ai une création "en montée" de mon arbre,jusqu'à l'envoi de la requete à CQG (limité par les tirets oranges "en of step 1".

Le traitement du résultat est indiqué dans le step 2.

A chaque bloc un traitement à la montée (Init) et un traitement à la descente (ProviderResult). Le resultat est envoyé par Event (Result()) au bloc créateur.

ma DB est un SQL Server, sur le réseau. Chaque bloc prend les informations de hiérachie le concernant (GetHierarchyDetails()), qui lui permettent de savoir à quel(s) bloc(s) il doit demander des informations.

Je suis conscient que je donne peu d'informations, mais je doute que fournir tout le ppt soit pertinent :oops:

votre traitement prend 5 minutes, il faut donc maintenant pouvoir découper ces 5 minutes sur chaque traitement pour savoir lequel est à améliorer

le stopwatch permet de faire ca

OK,

je comprends déjà mieux cette histoire de décompte possible.

Je tente donc un code avec

Code:

---

1 2 3 4 5 6 7 8 9 10

Protected Overrides Sub HandleResult(parentBlock As BLOCK, varResult As List(Of Output)) Dim chrono As Stopwatch chrono = Stopwatch.StartNew() Traitement() Dim Relaunchthr As New ThreadRelaunch(Me, parentBlock, varResult) ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf Relaunchthr.ThrFunc)) RaiseResult(Me, varResult) chrono.Stop() MsgBox(chrono.ElapsedMilliseconds) End Sub

---

pour savoir ce que prend un morceau de code qui est appelé plusieurs fois, il faut une variable de classe, et faire .Start / .Stop pour que ca se cumule
si le morceau de code est appelé plusieurs fois et par plusieurs instances il faut une variable shared, ca te permettra d'avoir un temps global pour le morceau de code tout appel confondu

quand tu arriveras avec la somme de tous tes stopwatch a avoir a peu près le temps total tu pourras en déduire sur quelle partie du code il nous faudrait des détails pour t'aider (le code utilisé dans les grandes lignes, genre telle classe raise un event, tant d'instances exécute alors tel code, cette requete est exécutée tant de fois etc...)

OK, premier résultat de test :
- la constrruction de mes arbres prend environ 30 secondes, pour 200 blocs.

Le temps de création des blocks augmente avec le nombre de block existants.

En effet, avant de créer un block, je teste s'il n'existe pas déjà dans la liste des blocs existants. J'y teste les paramètres associés et s'ils matchent, je redirige le lien vers le bloc existant au lieu d'en créer un nouveau.

Ca évite de créer des doublons.

Bon par contre, dans mon cas de figure, c'est marginal le cas de demande exactement similaire. Donc au lieu d'avoir des temps de création qui s'échelonnerait entre 8 ms et 330 ms, j'ai déjà cet aspect d'optimisation :roll:

il aurait été bien de préciser comment tu fais pour vérifier la présence de doublons, si tu parcours un tableau ou une collection simple c'est normal que le temps grimpe à force de tout relire (et avec la collection grandissante en plus ...)

il existe des collections qui hashent une valeur et dans ce cas la vérification de présence n'a pas besoin de parcourir toute la collection mais peut vérifier par dichotomie sur un tri du hash des clés
une des solutions est alors parallèlement au remplissage de ta collection d'en remplir une qui sert juste pour la recherche de doublons
si tu as plusieurs propriétés à tester, le mieux est de hasher tout ensemble je pense

encore une fois sans détails (propriétés, types, méthodes de recherche de doublons) on ne pourra pas te donner LA solution idéale, mais juste des pistes de recherche, c'est alors à toi de trouver la bonne solution


la liste des collections de .net
http://msdn.microsoft.com/fr-fr/library/ms233837.aspx
en utilisant la ou les bonnes tu devrais pouvoir obtenir des choses comme 8ms/15ms au lieu de 8/330

En fait, c'est un peu plus compliqué que cela :

chaque bloc a sa liste de paramètres, ceux ci sont soient obligatoires, soit optionnels, soit non comptés. Chaque parametre a 1 ID et 1 valeur.

Je boucle sur la liste des blocs, si le type de bloc est identique alors je fais un test sur la liste des parametres pour les comparer et savoir s'ils sont équivalents (donc seuls les parametres obligatoires et optionnels sont comparés).

Je passe mon temps à faire des comparaisons dans des listes en fait :aie:

Je pensais faire un comparateur en concaténant toutes les valeurs mises bout à bout lors de la création du bloc. On comparerait alors seulement une chaine à une autre et non pas tous les champs de la structure...

Ce qui me désole c'est que mon process d'origine était semble-t-il bien conçu, mais je n'avais pas du tout pensé que le temps de traitement allait etre aussi excécrable... :calim2:

qu'il y ait plein de valeurs qui entre en jeu pour la comparaison ne retire rien à ce que j'ai dis, il faut utiliser des collections intelligentes qui feront ca mieux que toi ...

OK,

j'envie tellement mes élèves d'avoir eu des cours de vb.net :lol:

Je prends les étapes une par une :ccool:

Bon alors, déjà au lieu de taper toute la liste, j'ai effectivement fait un Contains dans ma liste avec les concaténation, on a plus que du 4 à 8ms de création par block :fou: