Discussion :

[Jean-Philippe André]

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.

[Jean-Philippe André]

Je continue ma description, si ca peut aider

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

[Pol63]

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

[Jean-Philippe André]

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

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" :/

[Pol63]

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

[Jean-Philippe André]

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...