Hauptgedanke

Am Skill ändert sich nichts, und sein Verbrauch steigt trotzdem. Die Datenbank wächst von 88 auf 138 Analysen, und alle Phasen, die sie erneut lesen, kosten mehr. Die Anweisungsdatei wächst im Lauf der Anpassungen um die Hälfte, und dieser Zuschlag wird bei jedem Aufruf bezahlt.

Bei competitor_analyze haben zwei umgesetzte Optimierungen 186 000 Einheiten eingespart, und das Datenwachstum hat im selben Zeitraum 71 000 davon wieder aufgezehrt. Auditierte Kosten tragen also ein Datum: Sie sind eine Messung an einem Szenario zu einem Zeitpunkt, keine Eigenschaft des Skills. Daher die drei Momente, in denen das Audit wiederholt wird — beim Deployment, wenn das Limit schneller erreicht wird als zuvor, und regelmäßig beim schwersten Skill.

Warum das wichtig ist

Das verhindert, eine Optimierung als erledigt zu betrachten: Ein erzielter Gewinn kann aufgezehrt werden, ohne dass es jemand merkt, und der Skill ist ein paar Monate später wieder der erste Verdächtige.

Es macht das Audit außerdem zu einem wiederkehrenden Vorgang statt zu einem einmaligen Projekt.

Nuancen und Grenzen

Die Drift ist nicht immer ein Rückschritt: Ein Skill, der mehr kostet, weil er mehr verarbeitet, hat sich nicht verschlechtert. Was sich verschlechtert, sind die Kosten pro Einheit nützlicher Arbeit, und die Gesamtsumme zeigt das nicht.

Offene Fragen

• Wer bemerkt, dass eine Optimierung vom Datenwachstum aufgefressen wurde, wenn sich die Gesamtsumme doch nicht bewegt hat?