Performance amortie
Pour certaines applications, chaque opération d'un type abstrait doit être exécutée de manière efficace. C'est le cas en particulier d'applications de type temps réel pur lesquels le temps de réponse doit être borné. Cela contraint forcement les implémentations possible du type abstrait.
Pour d'autres applications, ce n'est pas le temps de réponse que est le plus important, mais le temps total de traitement. Ce sont des application de type traitement par lot. Pour ce type d'application, il suffit qu'une suite d'opérations exécute de manière efficace. Le temps d'exécution d'une suite de n opérations est alors divisé par n afin d'obtenir le temps d'exécution amorti.
Si chaque opération n'a pas besoin d'être exécutée de manière efficace individuellement, cette liberté supplémentaire permet des implémentations plus efficace de certaines opérations de certains type abstraits. Un exemple typique est la pile impérative. Si chaque opération doit être efficace, alors une implémentation par une liste s'impose. S'il suffit que l'exécution d'une suite d'opérations soit efficace, alors on peut choisir un tableau. Le fait que le tableau doit être réalloué de temps en temps (avec un coût proportionnel au nombre d'éléments) fait qu'une opération peut prendre un temps d'exécution arbitrairement élevé, mais cela se produite assez peu fréquemment pour que le temps amorti reste faible.
Les applications interactive sont dans une catégorie intermédiaire entre les application de type temps réel et de type traitement par lot. Pour ce type d'applications, les contraintes sur le temps de réponse ne sont pas aussi sévères que pour les applications interactives, mais ne doit pas dépasser quelques dizaines de millisecondes dans la grande majorité des cas. Chaque application doit alors déterminer si une performance amortie est suffisante.