Taille des variables et performances

[Gutsy]

Bonjour,

Je développe un gros programme qui travaille sur des tables assez conséquentes (10k lignes x 200 variables facilement, traité avec énormément d'étapes data/sql sur des dizaines de macros, pour un temps d'exécution de 30h sur un bi-Xeon/64Go de RAM/raid0 SSD).

Je cherche donc à gagner un peu en performances, et je me pose la question de l'importance de la définition des variables.

Actuellement, elles ont toutes les tailles/formats standards, sauf à la fin au moment du reporting où je les met en forme. L'idée serait donc, dès l'input du programme, de mettre en forme toutes ces données de manière à ce que le traitement se fasse de manière optimale.

Pensez-vous qu'il soit possible de gagner en performance de cette manière ?

L'idée principale était d'adapter précisément la taille de la variable à son contenu (par exemple, une variable contenant une année serait mise en taille 4, plutôt qu'en 8 comme actuellement).

Cependant, j'ai lu récemment dans un article qu'adapter les variables de cette manière, bien qu'améliorant le temps d'écriture/espace disque, consomme beaucoup plus de processeur que d'avoir des tailles de variables uniformes dans un même dataset.

Est-ce vraiment significatif ? Qu'en pensez-vous ?

Merci

[sasadm]

Bonjour,

La taille des variables est un des leviers d'optimisation à ne pas négliger mais dans ton cas c'est la multiplication des lectures de la table par étapes data et sql qui entraine le dérapage du temps de traitement d'autant que la table en entrée n'a pas l'air monstrueuse.

[Gutsy]

Je sais que le temps de traitement est principalement dû au nombre d'étapes, mais c'est malheusement très compliqué à revoir car le travail réalisé par le code est extrêment complexe.
Cela fait quand même l'objet d'un projet d'optimisation en cours, mais nous cherchons à trouver d'autres leviers, et le travail sur les données nous a paru intéressant à mener.

Ce qui m'intrigue beaucoup, c'est de savoir quel est la meilleure façon de faire : uniformiser le taille des variables ou bien avoir une taille de variable strictement définie par rapport à son contenu (taille 4 pour une année par exemple). Je serais parti sur la seconde solution, mais la lecture d'un article mettant en garde contre l'impact processeur de ce type de différenciation m'a poussé à creuser un peu plus le sujet avant de lancer le projet.

[sasadm]

Pourrais-tu donner la référence de cet article ?

[jmarandet]

Bonjour Gutsy,

A première vue, sans connaître parfaitement les contraintes de votre projet, l'idée de formater la table en input présente les avantages/inconvénients suivants :
- Avantages : Peut être gagner en volume de stockage, et par là faciliter le travail de calcul/mise en mémoire tampon de lecture pour la chaîne de traitement qui va suivre. Le gain espéré est-il réel ??? Votre machine me semble être une bête de course.

- Inconvénients : Nécessite, pour ce faire, d'intercaler un traitement très gourmand en ressources et potentiellement dangereux (réduire les tailles de variables à postériori peut présenter un risque de perte de données).

Avant de m'aventurer sur une piste aux perspectives aussi sombres, je serais d'avis de me renseigner sur d'autres possibilités :

1. Si vous utilisez l'option fullstimer, peut être pourriez vous identifier les points noirs de votre processus et faire une remise à plat ciblée ?

2. Si les traitements se focalisent sur des variables ou catégories de données particulières, avez-vous envisagé d'indexer vos données ?

[LaurentP75]

Bonjour,
Je pense que les conseils proposés ci-dessus sont pertinents.

Mais je prévoirai aussi de travailler sur les thèmes suivants :

1) si le domaine de définition des modalités d'une variable est connu, adapter sa longueur en octet afin de minimiser la place occupée, autant en mémoire que sur disque, essentiellement pour les variables caractères.

2) pour les nombres Entiers (jamais de décimale) prenant peu de valeurs, avec peu de chiffres significatif, les mettre en Length 4, sinon 8.

3) Si beaucoup de variables sont caractères, de longueurs variables, de remplissage variable, utiliser lors de la création des DATA les options
(Compress=YES Pointobs=Yes). La perte de temps lors des compression/décompression est largement récupéré lors des accès disques ou accès réseau.

4) ne pas oublier de "Dropper" les variables temporaires des étapes data (indice de boucles Do par exemple) et les variables inutiles créées en systématique par certaines procédures SAS (telle les Percent d'un Freq si l'on utilise que les COUNT).