Temps CPU, temps perçu, tant pis

Si vous avez joué avec des processus dans votre jeunesse, vous vous souvenez peut-être des expressions « CPU time » et « elapsed time« . La première désigne le temps réellement consommé sur le processeur utilisé, tandis que la seconde désigne le temps perçu, celui passé devant son poste de travail à attendre que le processus ou la tâche considérée s’achève.

J’ai tendance à toujours apprécier la « vraie vie » à l’aune de ces deux grandeurs: temps perçu, temps CPU, et ce, quel que soit le phénomène considéré.

Demandez par exemple à quelqu’un de vous rédiger une courte note sur un sujet quelconque, une tâche qui ne doit pas prendre plus de 10 à 20 minutes, et laissez-lui une semaine pour vous rendre son travail. Dans la quasi totalité des cas, vous pouvez être certain qu’on vous rendra ce une fois la semaine échue. Temps CPU = 20 minutes maximum, temps perçu = 1 semaine.

Pourtant, vingt petites minutes auraient suffi; peut-être pas dans l’immédiat ni le jour même, mais le lendemain au plus tard. Mais non, appelez cela paresse, procrastination, optimisation, gestion des priorités, rien n’y fait, nous ne pouvons nous empêcher de faire diverger ces deux grandeurs.

Là où cela devient encore plus intéressant, c’est que ce phénomène se produit dans les deux sens, qu’on soit observateur en charge de la mesure, ou bien exécutant, objet de la mesure. Repousser une tâche jusqu’à la dernière minute, nous l’avons tous fait, il faut bien le reconnaître.

Pourtant, cette différence temps perçu / temps CPU peut avoir des incidences fâcheuses. Tout remettre à la dernière minute, c’est se priver de marge de manoeuvre, de procédure de repli, de marge d’erreur. C’est la posture du casse-cou, qui considère qu’il fera bien du premier coup, même s’il sait implicitement que rien ne peut l’assurer.

Ramener la durée d’exécution d’une tâche à la CPU réellement nécessaire, voilà une preuve d’efficacité. Prêts à mettre en oeuvre dès ce soir?