Re: [Tsp-devel] Problème de sampling.

[dufy]

Salut Stef.


Je ne comprends pas bien ou est ton problème.
Tu demandes un sous ensemble des 1000 symboles : Prenons comme exemple
que tu obtiennes les provider_global_index [ 1 10 100 200 300 400 500
600 700 999 ] 
Ensuite tu bâtis un tableau d'index inversé, de 1000 int (le max que tu
as demandé au provider avant). Au positions [ 1 10 100 200 300 400 500
600 700 999 ] tu mets [ 0 1 2 3 4 5 6 7 8 9 ] et -1 ailleurs.
Dés que tu reçois un pgi, tu trouves en une indirection l'index que tu
veux avec reverse_tab[pgi], et cela ne te prends rien en CPU.

Je pense qu'il ne faut pas que tu demandes tous les symboles, si tu peux l'éviter. Mais peut-être j'ai mal compris ton blocage.

Y++

2005/11/26, STEF <address@hidden>:

Salut à tous,

Bon, je n'ai pas encore commité la gestion des sessions sous GDisp+
car suite aux dernières recommandations de Erk, j'ai remodelé ma gestion
du sampling et je tombe maintenant sur un problème que je vous expose
ci-dessous.

Jusqu'à présent, GDisp+ demandait aux divers providers disponibles la
TOTALITE des symboles mis à disposition.

ETAPE 1 :
   ...
   provider = TSP_consumer_connect_url(url);
   ...
   TSP_consumer_request_open(provider,(gint)NULL,(gchar**)NULL);
   ...
   TSP_consumer_request_information(provider);
   ...
   providerInfo = TSP_consumer_get_information(provider);
   ...

Puis j'obtenais les symboles via :

   providerInfo.val et providerInfo.len

La mise en sampling se faisait de la façon suivante :

ETAPE 2 :
   ...
   TSP_consumer_request_sample(provider,&sampleList);
   ...
   /* pour avoir les bons index */
   realList = TSP_consumer_get_requested_sample(provider);
   ...
   TSP_consumer_request_sample_init(provider,
                                    (TSP_sample_callback_t)NULL,(void*)NULL);
   ...
   while (keepOn == TRUE) {
     ...
     TSP_consumer_read_sample(provider,&sampleValue,&sampleHasArrived);
     ...
   }
   ...
   TSP_consumer_request_sample_destroy(provider);
   ...

La variable sampleValue.provider_global_index permettait de retrouver
facilement le symbol concerné dans la table globale issue de l'étape 1.

Aujourd'hui, GDisp+ offre la possibilité de charger une session composée
d'un sous-ensemble des symboles existants, et ce SANS DEMANDER L'ENSEMBLE
DES SYMBOLES AU PREALABLE.

Par exemple avec un tsp_stub_server qui offre 1000 symboles, la session
peut n'en contenir que 10 répartis dans plusieurs plots graphiques.

!!! >> Donc en mémoire, GDisp+ a bâti une table de 10 symboles.

Or les index obtenus soit par TSP_consumer_get_requeted_sample, soit par
sampleValue.provider_global_index continuent à arriver avec des valeurs
comprise entre 0 et 999.

J'ai peur des perfos car je dois faire une RECHERCHE MANUELLE des symboles
chaque fois qu'une sampleValue arrive, cad autant de fois qu'il y a de
symboles en sampling toutes les 10 ms.

Que feriez-vous ? Continuer de demander les 1000 symboles avant de charger
la session auquel cas le sampleValue.provider_global_index redevient
utilisable ?

Euskadi.











_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel