Das ist nicht ganz einfach zu beantworten. Ich versuche es mal:
Die simulierte Umgebung hat eine Grundfläche von ca. 3000*2000 Einheiten (ob Inch, cm oder mm ist nicht festgelegt). Die Auflösung der Karte wird durch SLAM_RASTER (hier 25) bestimmt. Ein Feld auf der Karte ist also 25x25 Einheiten groß.

Wäre die simulierte Umgebung z.B. eine reale Wohnung mit der Grundfläche 12x8m, würde sich als Einheit 4mm ergeben. Damit hättest Du eine Feldauflösung von 10x10cm. Wenn Dir diese Auflösung zum Navigieren reicht, kannst Du mit einer Bearbeitungszeit von 500ms/Scan bei 120 Messungen/Scan für den SLAM rechnen.

Pragmatischer Ansatz, wenn Du noch keinen ESP32 zum Testen hast - ich stelle es gerade für Dich um und lasse es laufen:

Bei SLAM_RASTER = 12,5 (bezogen auf obiges Beispiel also 5x5cm für ein Feld auf der Karte) zeigt mir meine Messung Durchlaufzeiten von bis zu 850ms.

Bei SLAM_RASTER = 50 (bezogen auf obiges Beispiel also 20x20cm für ein Feld auf der Karte) zeigt mir meine Messung Durchlaufzeiten von etwa 420ms.

(Man merkt schon: Die Anzahl der Fließkommaoperationen sinkt durch die Änderung der Auflösung nicht. Die ergibt sich aus "Anzahl Variationen * Messungen pro Scan". Was sich proportional zur Auflösung ändert, ist die Anzahl der Ganzzahloperationen (der Bresenham-Line Algorithmus), die gehen aber auch bei 240MHz recht fix.)

Also grob geschätzt: Typische Wohnung = 500ms Zykluszeit für den SLAM - es fehlen noch Pathfinder, Pathfollower und die intellektuelle Aufgabe, die Karte in Bahnen für einen Staubsauger zu unterteilen oder zeitgesteuert Überwaschungsrouten abzufahren. Das wären sinnvolle Anwendungen, bei denen der Aktualisierungszyklus irgendwo im Sekundenbereich liegen muss

Nicht sinnvoll wäre es, eine Katze damit spielen zu lassen.