Die 68020 hatte eine kleine Pipeline (damit kann die Ausführung eines Befehls schon begonnen werden während der vorige noch bearbeitet wird). Allerdings muss die Pipeline oft weggeworfen werden, d.h. der Nutzen ist gering und braucht ein optimiertes Programm (z.B. durch Umstellung von Befehlen ohne nötige Reihenfolge).
Außerdem wurde ein kleiner Cache (256 Bytes) vorgesehen, das vermeidet viele der sonst eventuell nötigen Waitstates. Allerdings profitieren dabei vor allem kleine, oft hintereinander genutzte Programmteile ohne zu viele Speicherzugriffe für Daten. Kleine Schleifen, die mit Daten in Daten in den Registern arbeiten sind also ideal.

Bei der 68030 kommt jetzt noch ein Datencache von 256 Byte hinzu. Damit werden Rechnungen auf kleinen Datenmengen gut beschleunigt, aber bei "richtigen" Programmen geht die Trefferquote schnell in den Keller. Nur wenige Variablen (die bereits bevorzugt Register belegen) profitieren davon, meist wirft ein Zugriff etwas anderes raus, was dann ein paar Takte wieder geladen werden muss. Der Cache ist also besser als nichts, aber nicht z.B. mit den 32 KB bei Rechnern mit 80386 und 33 MHz vergleichbar ist.

Der Zugriff auf Hashtables ist nur ein kleiner Teil der Berechnung eines Knotens, d.h. der Zeitaufwand für Waitstates bei vier oder sechs Zugriffen pro Knoten (8 oder 12 Bytes erst lesen und dann ggf. speichern) spielt letztlich keine große Rolle.
Es ist daher eine durchaus plausible Rechnung, wenn statt einer externen Cachelogik mit extra RAM (mehrere Chips für 32 Bit-Zugriffe) gleich statisches RAM für den normalen Speicher vorgesehen wird und für die Hashtables langsameren und preiswerteren Speicher. Außerdem wird durch die Trennung die Aufrüstung einfacher und preiswerter möglich.