FileMaker : Performance et mobilité (2)

Mesurer la performance

Le sujet que nous avons traité dernièrement, grâce à la question de Stéphane sur la construction de modèles avec un en-tête unique pour plusieurs modèles, nous a amenés à prendre conscience que l’on pouvait certes gagner du temps en tant que développeur dans la réalisation de modèles FileMaker, mais également viser à de meilleures performances logicielles (1) 😉

Mais avant de s’intéresser au comment accroître la performance de votre solution, on peut s’interroger : comment peut-on savoir si elle est ou non performante ?

Trois critères nous permettent de l’évaluer.

Le premier est la vitesse de démarrage de votre solution.

Si vous avez le sentiment que cela met « trois plombes » avant que vous n’accédiez à un premier modèle et que celui-ci soit totalement opérationnel sur votre écran, c’est qu’il y a un problème !

De telles situations peuvent se produire si au démarrage de votre solution, vous avez prévu l’exécution d’un script particulièrement important, qui remet par exemple à jour des calculs sur tous les enregistrements de votre base…

Le deuxième est la vitesse à laquelle un utilisateur – ou un script – exécute une tâche.

Par exemple, vous cliquez sur un bouton qui vous emmène sur un modèle présenté en vue Liste. Dans cette liste, se trouvent de nombreux calculs, qui se réactualisent dès qu’on les affiche. En outre, le bouton qui se rend sur ce fameux modèle ne se contente pas d’y aller : une fois arrivé sur le modèle, il effectue une recherche et, sur le résultat obtenu, trie les enregistrements. Étant donné le nombre d’enregistrements contenus dans la table active, les calculs et les rubriques à afficher, la recherche et le tri, l’ensemble peut prendre plusieurs minutes avant de s’afficher correctement à l’écran…

Enfin, le troisième critère se rapportant à la performance de votre solution est la durée qu’il vous faut pour obtenir le résultat d’une recherche, et ce, quelle que soit la manière dont votre recherche est effectuée (recherche avec le mode Recherche, avec l’outil de recherche rapide, avec les liens (2)…).

Amusez-vous à mesurer la performance de votre solution. À l’aide d’un chronomètre, voyez combien de temps vous perdez à « l’allumage » de votre bolide FileMaker solution ( 😉 ), en combien de temps s’exécute tel ou tel script, en combien de temps vous obtenez les résultats d’une recherche multi-critères et multi-requêtes…

Attention cependant…

Mesurer les performances de votre solution FileMaker semble être une attitude totalement objective puisque vous obtenez des résultats chiffrés : démarrage = 3 secondes, recherche  = 5 minutes et 4 secondes, etc.

Pourtant, il s’y mêle aussi beaucoup de subjectivité. Ainsi, le seuil de tolérance d’attente n’est pas le même d’une personne à l’autre. Pire, suivant l’état d’esprit d’une même personne, ce seuil de tolérance est ou non largement dépassé pour la même action. Ainsi, le jour où vous êtes déjà très en retard, sur le départ, et qu’il vous faut absolument sortir cette liste et l’imprimer et que cela tarde à arriver, votre seuil de tolérance est largement dépassé ! Alors que dans un contexte où vous avez tout votre temps, la même opération vous paraît toute naturelle…

En outre, en fonction du type d’action effectuée, vous ne vous attendez pas à avoir à patienter de la même manière.

Pour réaliser un rapport trié avec plusieurs milliers d’enregistrements, cela vous paraît logique que cela prenne du temps. Et de ce fait, vous acceptez de patienter un peu. En même temps, il ne faut pas que cela soit excessif non plus 😉 En revanche, se rendre sur un modèle doit, d’après votre expérience, être instantané. Par conséquent, vous ne comprenez pas que cela ne le soit pas !

La mesure de la performance est donc quelque chose d’objectif ET de subjectif, et dans tous les cas, de relatif à une situation donnée.

Un environnement de plus en plus performant

Prenons enfin un dernier aspect du problème.

Les outils dont nous disposons depuis une trentaine d’années sont devenus de plus en plus performants. C’est-à-dire, conjointement, plus ergonomiques, plus sûrs (du moins j’espère 😉 ) plus rapides et plus puissants !

Un petit exemple : le stockage de nos données sur des disques externes pour en faire des sauvegardes. J’ai des souvenirs terrifiants de disquettes, puis de disque SyQuest qui refusaient de monter sur le disque dur, qui étaient lents, limités en capacité, qui s’endommageaient, etc. etc. Puis sont apparus les CD, les DVD, les clés USB, et maintenant le Cloud… Stocker des données se fait maintenant rapidement et simplement…

Or, ce que nous connaissons dans un domaine de l’informatique, nous avons tendance à le reproduire dans tous nos domaines d’utilisation : si tel logiciel, si tel site Web sont rapides, alors il est inconcevable que la solution FileMaker que nous utilisons tous les jours ne le soit pas également !

En tant que développeurs FileMaker, nous sommes alors confrontés à deux problèmes :

Un problème d’héritage

Il peut arriver – et cela est courant 😉 – que nous héritions d’une très ancienne base de données FileMaker. Développée comme on a pu, avec les moyens et les compétences du moment. La difficulté est alors de savoir/pouvoir faire évoluer une telle base vers quelque chose d’acceptable aujourd’hui et de compatible avec nos outils actuels.

Un problème d’évaluation des services rendus

Entre une petite app téléchargée sur votre smartphone et la gestion complète de votre activité grâce à FileMaker sur votre poste de travail, il y a tout un monde ! Il est facile pour une toute petite app d’être performante – et donc bien conçue – si de toute manière, elle ne fait pas grand chose, c’est-à-dire uniquement la tâche pour laquelle elle a été conçue ! Avec FileMaker, vous pouvez bien entendu réaliser de telles apps ultra performantes ! Mais l’enjeu ici est de comparer ce qui est comparable : est-ce que la même solution, conçue et réalisée dans FileMaker et dans Access de manière optimale aura la même performance dans l’un ou l’autre environnement ?

J’ajouterais en outre, même si cela n’appartient pas aux trois critères de performance cités ci-dessus, que l’ergonomie de votre solution contribue à sa performance. Si l’utilisateur perd 5 minutes à chaque utilisation à chercher le bouton qui lui permet de réaliser telle manipulation, alors ce n’est quand même pas le top en termes de performance 😉

En évoquant tous ces aspects, j’en ai laissé un de côté, et qui n’est pas négligeable : le partage des données… Mais j’aurais peur de vous « gaver » avec trop d’informations aujourd’hui 😉

Alors, je procrastine… et je reporte à la semaine prochaine le traitement ce sujet et je vous souhaite une excellente semaine  !

Marie-Charlotte Potton

(1) : Retrouvez ces articles depuis le premier de la série, QR 92 – FileMaker : des en-têtes qui se répètent ?

(2) : La recherche dans FileMaker est depuis l’origine du logiciel un de ses fleurons, si je peux m’exprimer ainsi, et n’a cessé de s’enrichir de nouvelles pratiques. Bien savoir recherche dans FileMaker, et pour cela choisir le bon outil, est essentiel pour obtenir de lui ce que l’on en attend… Nous avons consacré deux cahiers pratiques à cette question, l’un et l’autre correspondant à au minimum une demi-journée de formation en présentiel. Le premier traite essentiellement du mode Recherche, tandis que le second vous invite à automatiser les recherches notamment à l’aide de scripts. Un pack de fiches Astuces complète ces cahiers avec la recherche rapide. Enfin, la création de tables et de liens concerne également ce sujet puisque créer une table externe, c’est réaliser une requête à l’aide d’un filtre supporté par un lien 😉

Pour retrouver facilement ces tutoriels, saisissez dans le moteur de recherche de la librairie les mots clés « recherche » et « lien » : avec le mot  « recherche » ou avec le mot « lien ».

Premier article – Article suivant

Tags: Mobilité, Performance