You can find an english version of this article here :smirk:

L’AttributeManager est un transformer présent dans la boite à outils de tout bon FMEiste depuis 2016.

Il permet notamment de :

  • renommer des champs
  • supprimer des champs
  • créer des champs
  • définir les valeurs d’un champ que ce soit par une opération arithmétique, des valeurs conditionnelles ou une concaténation de champs

Avant 2016, chacune de ces fonctions étaient possibles dans FME grâce à des transformers particuliers ; AttributeCreator permet, par exemple, de créer de nouveaux champs et AreaCalculator de calculer les superficies de polygones.

On pourrait donc penser, que 5 ans après sa release, les utilisateurs se soient habitués à son fonctionnement (ce qui est vrai en grande partie au vu de sa 2nde place dans le classement des transformers), et que Safe aurait pu décider d’abandonner ses prédécesseurs.

Mais il n’en est rien, ils continuent de cohabiter joyeusement.

Pourquoi un test de performance ?

Je formule donc l’hypothèse qu’en fonction des cas d’usage, les performances ne doivent pas être les mêmes. Cela pourrait expliquer que des transformers, ayant des fonctions similaires, existent encore en parallèle.

Voyons voir cela d’un peu plus près, en prenant, pour le test, 4 transformers que l’AttributeManager pourrait remplacer fonctionnellement parlant :

Pour réaliser ce test, j’ai récupéré les parcelles PCI (Plan Cadastral Informatisé) de la Charente-Maritime, environ 1Go de données, avec 1 671 935 lignes.

Nous appellerons le transformer AttributeManager *AM* dans la suite de cet article afin d’éviter de surcharger la lecture.

Vous trouverez le workbench qui m’a permis de réaliser les tests de performance ici.

Test de l’AM en face to face avec ses ancêtres

Pour tenter de gagner un peu de temps, le Feature Caching est activé pour l’ensemble des tests suivants, uniquement après la lecture de la donnée entrante.
A chaque fois qu’un test de process est indiqué, j’ai fait tourner 5 fois le même transformer (ou enchainement de transformers) et fait la moyenne des 5 temps.

Concernant l’AM face à ses ancètres, un par un, et pour les mêmes tâches, vous trouverez le résumé des temps ci-dessous :

comparaison 1V1

Pour l’instant, hormis sur la création d’attributs où un doute peut subsister (l’écart étant plutôt mince), les “anciens” transformers spécifiques apparaissent comme plus performants que l’AM.

C’est un peu comme si vous aviez un Leatherman et un tournevis cruciforme sous la main, et que vous n’avez que des vis cruciforme à poser. Vous irez sans doute plus vite en vous servant du tournevis.

Test de l’AM en remplacement d’un enchaînement de ses prédécesseurs

Réalisons maintenant des enchaînement des 4 précédents transformers comparés aux même taches effectuées dans l’AM.

Avant toute chose, il est à noter qu’un seul AM peut, parfois, ne pas remplir les mêmes fonctions que les transformers à tache unique.
Par exemple, si vous souhaitez créer un nouvel Attribut 2 à partir d’un Attribut 1 déjà existant, et supprimer l’Attribut 1 dans la foulée.
Il suffit d’enchainer un AttributeCreator puis un AttributeRemover (ou AttributeKeeper pour ceux qui aiment cocher plein de cases :smile:).
Ici, un seul AM ne suffira pas.
En effet, si vous dites dans les paramètres de l’AM que vous souhaitez à la fois créer un champ à partir d’un attribut et le supprimer, il risque de ne pas comprendre ce que vous voulez lui faire faire…

Enchainement de 2 transformers :

comparaison 2V1

Enchainement de 3 transformers :

comparaison 3V1

Enchainement des 4 transformers mono taches :

comparaison 4V1

On se rend compte ici, que lorsqu’au moins 2 transformers historiques sont enchaînés, face à un unique AM, les gains de temps sont là.
Et il peut parfois même être 2x fois plus rapide !

J’imagine que l’AM est optimisé, lorsqu’il y a plusieurs taches à réaliser, pour qu’elles se réalisent le plus rapidement possible.

Pour reprendre la métaphore du Leatherman, si vous devez visser des cruciformes, redresser une tige et ouvrir une bière (il peut le faire !), cette fois, vous gagnerez du temps en prenant le Leatherman, plutôt que d’aller chercher chaque outil un par un dans votre boîte à outils.

Test d’enchainement d’AM

Un dernier test histoire de pousser un peu…

Que se passe-t-il si on se trouve dans le cas de figure évoqué plus haut de la création d’un Attribut 1 et d’un Attribut 2, puis d’un Attribut 3, lui-même dépendant des 2 premiers, mais que nous souhaitons echaîner avec la suppression des 2 premiers attributs créés ?

Clairement, un AttributeCreator + un AttributeKeeper font l’affaire.
Mais si nous souhaitons passer par de l’AM, il faudra en enchaîner 2 :

  • AttributeCreator (création d’un Attribut 1, Attribut 2 et d’un Attribut 3 = Attribut 1 + Attribut 2) + AttributeKeeper (on ne garde que l’Attribute 3) : 139 secondes
  • AM qui crée les 3 attributs + AM qui ne garde que l’Attribut 3 : 148 secondes

Assez logiquement, l’enchaînement de 2 AM est plus long que celui de 2 transformers historiques.

Si vous souhaitez utiliser 2 Leathermans différents, chacun pour des taches différentes, autant prendre les outils spécifiques, et vous gagnerez ainsi du temps !

Conclusion

Après ces quelques tests rapides, je pense qu’il y a du vrai dans mon hypothèse de départ.

En réalité, nous avons tout intérêt à utiliser un transformer historique type AttributeQuelquechose plutôt que l’AM, uniquement dans le cas où une seule opération est réalisée.

Dès lors, que plusieurs opérations sont enchaînées, il ne faut surtout pas se priver d’utiliser directement l’AttributeManager afin de gagner en temps de traitement !!

Métaphore du Leatherman. CQFD…

gif barack obama drop the mic

Même s’il est toujours de bon ton de se méfier de l’ordre dans lequel les opérations sont réalisées.
Comme dit précédemment, évitez par exemple, dans un même AM de supprimer un attribut si vous souhaitez réaliser un calcul de champ ou une concaténation sur celui-ci :smirk:.


N’hésitez pas à commenter directement en dessous, ou à m’envoyer un message sur Twitter, je vous répondrai avec plaisir :pray: !

Mis à jour :

Laisser un commentaire