Discussion :

[olivier.decourt]

J'ai un peu de mal à comprendre pourquoi dans mon cas en utilisant le langage macro, le traitement dur aussi longtemps. Le langage macro est bien chargé et "compilé" au préalable en mémoire ?

Je ne vais pas trop m'aventurer sur le pourquoi, mais si je peux tenter une supposition, ce serait que si les macro-programmes sont effectivement compilés à l'avance, chargés une fois en mémoire au moment du 1er appel, je ne pense pas qu'ils soient conservés indéfiniment en mémoire après utilisation. Donc il se pourrait que SAS perde du temps à relire la version compilée de %recherche, de temps en temps. Idem pour les macro-variables : elles sont en mémoire vive, jusqu'à saturation de l'espace qui les contient (la table des symboles). Il y a même une option SAS (MSYMTABMAX) pour indiquer la taille de cet espace, au-delà de laquelle les macro-variables sont écrites sur le disque. S'il y en a beaucoup, on perd à nouveau du temps.

Mais sans doute que de meilleurs spécialistes de la performance des codes SAS pourraient nous en dire plus.

[JeromeMATHIAS]

Bonjour Suistrop, si tu parle de ton code, c'est un calcul réalisé via le macro langage, qui n'est pas fait pour calculer mais plus pour générer du code.
Alors, les calculs il peut les faire, mais c'est très lent (alors OK c'est pas une explication mais c'est un fait constant) et il l'est de l'ordre de 1000 fois plus lent que si le code était rédigé en SAS pur.

30mn c'est environ 1800 secondes, divisé par 1000 ça fait 2 secondes, que VBA ne prenne que 15 secondes pour le faire alors qu'il faut 30mn pour le macro code n'est pas donc choquant à priori.

Sur l'origine de la lenteur du macro code peut être qu'Olivier aura une explication...(Bon Ok Olivier a repondu entre temps)

[suistrop]

Merci à Olivier et "jerome_pdv2" pour ces éclairages.

[joyeux_lapin13]

Bonjour à vous 3 et sincèrement merci pour votre implication et vos contributions.

Je suis assez full soudainement du coup je n'ai pas eu le temps de faire de test... enfin si, un tout petit et j'avoue que ton code m'a laissé sur les fesses Olivier... une telle rapidité d'exécution j'en reviens pas... il me tarde d'adapter ça à la macro finale mais là j'avoue que j'ai l'impression d'être encore un débutant en SAS et pourtant jusque là j'étais persuadé d'approcher la référence!

Dés que le code final sera terminé je le mettrai sur ce topic avec les articles références que j'ai histoire de faire connaître l'outil statistique plus amplement. Comme dit, je pense que l'intérêt premier du HUM n'est finalement pas de quantifier la liaison entre une variable quantitative X et une variable qualitative Y à K modalités (K quelconque) mais de dégager la tendance des distributions de X restreintez aux différentes modalités de Y (d'ailleurs la théorie fondamentale du HUM est un calcul d'aire qui peut se représenter comme plusieurs distributions liées par une série de cutoffs variant entre eux). Puisque plus on augmente le nombre de classes plus la probabilité d'avoir des k-uplets concordants croît très rapidement (ou plutôt celle d'avoir une unique kème discordance avec un k-1 uplets concordant augmente fortement). Ca reste un outil finalement peu différentielle et plus descriptif voir légèrement exploratoire.

Il y a de fortes chances que je revienne vers toi Olivier sur ton code. En effet, l'idée étant pour moi d'adapter cet algorithme aussi bien sous SAS que sous R. SAS ayant l'immense avantage par rapport à R de pouvoir écrire un code qui génère un code (les spécialistes en informatique comprendront à quel point ce type de programme, également faisable en ssh et condor entre autre, vaut de l'or dans le monde de l'automatisation). Comprendre correctement ce code devrait me permettre de trouver la subtilité pour le reproduire sous R.

Je vous tiens au courant dans la semaine prochaine qui vient. Encore merci à vous.

[olivier.decourt]

Justement Jérôme, maintenant qu'on en parle, est-ce que le compilateur macro fait réellement des calculs, ou est-ce qu'il les sous-traite au compilateur SAS ? C'est ce qui se passe, par exemple, quand on passe par %SYSFUNC. Le temps d'échange entre les 2 compilateurs pourrait en partie expliquer la "lenteur" du compilateur macro à faire un calcul.

Autre piste plus certaine, ces deux citations extraites de la doc SAS (ici et là) :

When the macro processor evaluates logical expressions that contain operands that represent numbers, it converts the characters temporarily to numeric values.

When the macro processor evaluates an expression that contains an arithmetic operator and operands that represent numbers, it temporarily converts the operands to numeric values and performs the integer arithmetic operation. The result of the evaluation is text.

Toutes ces conversions incessantes ont un coût en temps de traitement, c'est certain. Les mêmes opérations réalisées dans une étape DATA, où les variables ont des types, permet de les éviter et donc de gagner du temps.

[JeromeMATHIAS]

Je ne saurais répondre à ta question Olivier, le fait qu'il prenne tant de temps doit être dû à ce qu'effectivement le compilateur de macro code doit faire des aller retour entre "différentes" couches, mais ça fait un peu propos de café du commerce pour ma part et ma compétence s'arrête là, Géraldine aurait peut-être des idées plus exacte sur ce qu'il se passe réellement ?