Engineering-Update.
Photo Explorer, Constellations und ein schnelleres Mapsake.
Zwei ambitionierte Foto-Funktionen stellten die gleiche Frage: Könnte Mapsake deutlich mehr Arbeit leisten, ohne langsamer zu werden? Eine neue Benchmark-Suite für Simulator und Gerät verwandelte die Antwort in messbare technische Arbeit.
Eine Funktions- und eine Engineering-Version.
Dieses Update führt zwei der ehrgeizigsten Fotoerlebnisse von Mapsake ein: Foto-Explorer, das eine umfangreiche, kartografische Bibliothek durchsuchbar macht, und Konstellationen, das visuelle Verbindungen zwischen weit entfernten Orten aufdeckt.
Es enthält auch die am wenigsten sichtbare Funktion in der Version: eine permanente Performance-Benchmark-Suite. Diese Suite hat sofort die langsamsten gemeinsamen Pfade gefunden, die Korrekturen messbar gemacht und der App eine Möglichkeit gegeben, zu erkennen, wann zukünftige Arbeiten sie wieder verlangsamen.
Das Ergebnis ist nicht nur mehr Funktionalität. Mapsake ist deutlich schneller beim Umwandeln großer Fotoarchive in Orte, beim Finden von nahegelegenen Städten und bei der Planung einer Sternenkonstellation.
Photo Explorer durchsucht das Reisealbum, nicht den Kameraroll.
Der Photo Explorer beginnt mit den kompakten Metadaten, die Mapsake bereits für kartierte Fotos verwaltet. Dazu gehören Standort, Datum, Quelle, Kamera, Notizen, Höhe, Geschwindigkeit, Favoriten, Screenshots, Bearbeitungen und die innerhalb der App hinzugefügte Organisation.
Der Index bleibt auf dem Gerät. Eine Suche kann direkt erfolgen (z. B. Japan, 2024, iPhone, Favoriten) oder natürlicher formuliert werden, z. B. „Lieblingsfotos aus Italien letztes Jahr“. Die Abfrageebene wandelt die unterstützte Sprache in eine strukturierte Reihe von Filtern um, während ein deterministisches Vokabular und die Korrektur von Tippfehlern eine zuverlässige Ausweichmöglichkeit bieten.
Die Suche ist nur ein Weg, um die Bibliothek zu durchsuchen. Sammlungen zeigen nützliche Gruppen an, ohne dass Sie etwas eintippen müssen; der Kartenbereich schränkt die Ergebnisse geografisch ein; die Zeitleiste gruppiert sie nach Datum; gespeicherte und kürzlich durchsuchte Begriffe erleichtern wiederholte Fragen. Favoriten, Bewertungen, Tags, Beschriftungen und Notizen befinden sich in einer lokalen Nebenkomponente, sodass die Organisation eines Fotos das Original nicht ändert oder hochlädt.
Die wichtige architektonische Entscheidung besteht darin, dass jedes Tool den gleichen indizierten Schnappschuss verwendet. Sammlungen, Zeitleiste, Karte und Textsuche erstellen nicht jedes Mal eine neue 82,000-Fotowelt von Grund auf neu.
Der Index wird abgeleitet, während die persönliche Organisation dauerhaft ist.
Der Photo Explorer benötigte zwei Arten von Speicher mit sehr unterschiedlichen Lebensdauern. Suchfelder wie Ortsnamen, Erstellungsjahr, Kamera, Höhe und Quelle können aus den vorhandenen Metadaten von Mapsake neu erstellt werden. Ein Favorit, eine private Notiz, eine Bewertung, ein Tag oder ein Farbetikett wurden von einer Person hinzugefügt und können nicht als temporäre Cache-Daten behandelt werden.
Mapsake speichert benutzerdefinierte Organisationen in einer kleinen, für Backups geeigneten Nebendatei. Der größere Suchindex befindet sich im Cache, enthält keine Bilddaten, ist von Backups ausgeschlossen und kann immer dann neu generiert werden, wenn sich sein Schema ändert. Das erneute Scannen einer Bibliothek oder das Löschen abgeleiteter Daten löscht nicht die Arbeit, die jemand in die Organisation investiert hat.
Diese Aufteilung machte auch die Sicherungen ehrlicher. Verlustfreie JSON- und HTML-Sicherungen können Notizen und Organisationen enthalten, aber sie werden nicht zu riesigen Fotoarchiven. Apple Photos-Annotationen behalten eine stabile iCloud-Kennung, sodass eine wiederhergestellte Sicherung eine Verbindung zur lokalen Kopie auf einem anderen Apple-Gerät herstellen kann; Immich-Asset-Kennungen sind bereits in ihrer Quelle stabil.
Die erste umfassende Testumgebung erzeugte einen komprimierten Index von etwa 12.4 MB für 82,000 Fotos. Ein vollständiger geografischer Aufbau benötigte 2.61 Sekunden auf dem Entwicklungssimulator, ein späteres Wiederherstellen von der Festplatte benötigte 1.20 Sekunden, das Erstellen von Sammlungen benötigte 126 Millisekunden, und das tägliche Zeitachsenmodell benötigte 211 Millisekunden. Diese Zahlen gaben jedem Teil der Funktion ein eigenes Budget, anstatt alles hinter einer generischen "Suche"-Messung zu verstecken.
Der Photo Explorer erklärt auch, warum ein Element übereinstimmt. Ein Ergebnis kann angeben, dass es mit Kyoto, 2024, einer iPhone-Kamera, einer privaten Notiz oder einem ausgewählten Filter übereinstimmt. Diese kleine Information ist wichtig, wenn eine Abfrage natürliche Sprache mit mehreren genauen Steuerelementen kombiniert: der Benutzer sollte niemals raten müssen, was die Suchmaschine gemeint hat.
Die Suchsprache ist eine Schnittstelle und keine Lizenz zur Improvisation.
Jede unterstützte Abfrage wird letztendlich zu einer validierten Filterstruktur. Der direkte Pfad erkennt Orte, Daten, Quellen, Kameramodelle, Notizen, Favoriten, Bewertungen, Tags, Höhe, Geschwindigkeit, Screenshots und bearbeitete Fotos. Ein begrenzter Rechtschreibkorrektor kann Absichtswörter und bekannte indizierte Vokabulare korrigieren, schreibt aber keine privaten Notizen um.
Auf Geräten, die Apples On-Device Foundation Models unterstützen, kann der eingegebene Text ebenfalls in die gleiche eingeschränkte Struktur interpretiert werden. Nur die Abfrage und das aktuelle Jahr werden an dieses Systemmodell übergeben. Fotopixel, Metadaten-Indizes, Standorthinweise und persönliche Organisationen werden niemals übergeben. Ungültige Bereiche und unbekannte Werte werden abgelehnt, und der deterministische Parser bleibt die Ausweichlösung.
Die Benutzeroberfläche zeigt die Interpretation an und bietet einen Weg zurück zu den ursprünglichen Wörtern. Hier ist Cleverness nur dann nützlich, wenn sie überprüfbar bleibt. „Fotos in 3,000 Metern Entfernung vom letzten Jahr“ sollten sich gesprächig anfühlen, aber sich dennoch wie eine präzise Reihe von Filtern verhalten.
Constellations sucht nach Wiederholungen über große Entfernungen.
„Then & Now“ fragt, ob jemand an denselben Ort zurückgekehrt ist. „Constellations“ stellt fast die umgekehrte Frage: Welche visuellen Ideen haben sie an weit entfernten Orten wiederholt?
Der lokale Index extrahiert einen kompakten Satz visueller Signale und Motive aus geeigneten Reisefotos. Der Planer sucht nach Merkmalen, die für ein Bild charakteristisch sind, anstatt nur überall üblich zu sein, und verbindet dann Kandidaten aus verschiedenen Reisezielen. Türen, Küstenlinien, Skylines, Bergformen, Farben, Jahreszeiten und Komposition können zum Vokabular eines Themas werden.
Diese Threads sind in einen dreidimensionalen Himmel angeordnet. Der Benutzer kann sich darin umsehen, einen Sternenkonstellation öffnen, eine Verbindung aufrechterhalten oder verwerfen und einen Film mit einem Match-Cut abspielen, bei dem verwandte Fotos von einem Ort zum nächsten überblenden. Freigabekarten und ein Reel verwenden die gleichen gespeicherten Thread-Daten.
Die Extraktions- und Planungsarbeiten finden auf dem Gerät statt. Mapsake sendet keine Reiseliste an einen Bildanalyse-Dienst. Hintergrundprozesse können den Index im Laufe der Zeit erweitern, ohne dass beim ersten Start die gesamte Bibliothek geladen werden muss.
Der visuelle Index wurde so konzipiert, dass er kostengünstig angepasst werden kann.
Für jeden qualifizierten Eintrag führt Mapsake eine kleine Bilddekodierung durch und leitet mehrere Informationen ab: ein Vision-Feature-Print, rohe Klassifizierungsbezeichnungen, eine kompakte Farbpalette und eine Lichtklasse, die aus Standort, Zeit und Sonnenhöhe geschätzt wird. Der Feature-Print ist eine kleine numerische Beschreibung, die für die Ähnlichkeit verwendet wird; er ist kein Abbild des Bildes und kann nicht als solches angezeigt werden.
Der Index speichert rohe Klassifizierungsidentifikatoren anstelle der sofortigen Ersetzung durch produktorientierte Motive. Diese Entscheidung hat sich während des Tests mit echten Bibliotheken ausgezahlt. Die erste Motivliste enthielt Bezeichnungen, die vernünftig klangen, aber nicht tatsächlich in der unterstützten Taxonomie von Vision vorhanden waren. Da die rohen Bezeichnungen immer noch verfügbar waren, war die Neugestaltung von „Türme und Brücken“, „Boote und Häfen“ und späteren Motivgruppen ein schneller Bewertungsvorgang und nicht ein weiteres Scannen von Tausenden von Originalen.
Die Indizierung beginnt mit repräsentativen Fotos anstatt, die Bibliothek strikt von den neuesten zu den ältesten zu lesen. Fotos werden in ungefähren Ortszellen und Tagesgruppen zusammengefasst, wobei Wert auf nützliche Stillbilder und Abstände zwischen Aufnahmen gelegt wird. Der Planer durchläuft dann die Orte in Runden. Dies ermöglicht eine geografische Breite in jungen Phasen, während Hintergrundprozesse allmählich Tiefe hinzufügen.
Die erste Version wählte pro Ort ein Foto aus jeder Runde aus. Echte Daten von Geräten zeigten den Fehler: Die meisten Orte blieben unter dem für den Thread-Engine verwendeten Dreifoto-Minimum, sodass tausende indizierter Assets immer noch keine Kandidaten liefern konnten. Durch die Aufteilung jeder Runde auf drei Vertreter konnte der Index schneller nützlich gemacht werden, ohne sein Gesamtbudget zu erhöhen. Das ist genau der Grund, warum sowohl synthetische Testumgebungen als auch eine echte, unübersichtliche Bibliothek wichtig sind.
Der Extraktor arbeitet in seriellen Batches, führt Änderungen atomar aus, pausiert bei thermischer Belastung und überspringt die Hintergrundextraktion im Energiesparmodus. Apple Fotos-Miniaturen, die sich bereits auf dem Gerät befinden, werden zuerst verwendet; iCloud-spezifische Bilder können auf einen späteren Netzwerk-verfügbaren Durchlauf warten. Immich verwendet die gleiche visuelle Pipeline wie sein vorhandener Miniaturansichtsdienst.
Ähnlichkeit allein macht noch keine Geschichte.
Eine Feature-Distanz kann zwei visuell ähnliche Fotos finden, aber Constellations soll Verbindungen zwischen Orten finden, nicht Duplikate erkennen. Kandidatenfotos müssen aus Zielen mindestens 150 Kilometer voneinander entfernt liegen. Der Algorithmus berücksichtigt auch charakteristische Motive, ungewöhnliches Licht, die Jahreszeit und wiederkehrende Kalenderereignisse, bevor er eine Verbindung herstellt.
„Ausgezeichnet“ wurde zum schwierigen Teil. Ein früheres Bewertungssystem belohnte Signale, die an beiden Orten vorhanden waren. In der Entwicklungsbibliothek führte dies zu Hunderten von Verbindungen, die von Nacht und gemeinsamen Jahreszeiten dominiert wurden. Diese Signale waren technisch zwar vorhanden, aber keineswegs überraschend. Der Motor bewertet jetzt die Relevanz: Ein Signal ist wichtig, wenn es an beiden Orten ungewöhnlich stark ist, verglichen mit der gesamten Bibliothek der Person.
Dadurch änderte sich die Frage von "Enthalten beide Orte Nachtfotos?" zu "Sind beide Orte ungewöhnlich viele Nachtfotos für diese Sammlung?" Häufige Muster verschwinden im Hintergrund, während wiederholte Aufnahmen während der "Blue Hour", Türansichten, Häfen, Winterlicht oder einer wiederkehrenden Urlaubszeit aussagekräftig werden können.
Visuelle Kandidaten verwenden mehrere Vertreter pro Ort anstelle eines einzelnen, zufälligen Paares. Thread-Identifikatoren werden aus ihrem Ort und ihrer Familie abgeleitet, sodass dieselbe Verbindung ihre Identität nach einer Neubewertung beibehält. Der Status 'gespeichert', 'abgelehnt' und 'gesehen' bleibt daher erhalten, und ein abgelehnter Thread erscheint nicht erneut, nur weil die Engine erneut ausgeführt wurde.
Das Layout des Himmels wird ebenfalls vorab berechnet und ist deterministisch. Geografische Positionen definieren die Knoten, die Stärke der Verbindungen zieht verbundene Orte zueinander, und ein kleiner, zufälliger Jitter verhindert exakte Überlappungen. Die Live-Oberfläche kann zwischen einer globusartigen Geografie und dem fertigen Sternbild mit einem einzigen Übergangswert wechseln; sie führt keine batterieintensive Physiksimulation in jedem Frame durch.
Der Match-Cut-Film verwendet Vision-Attention-Saliency, um die sanfte Kamerabewegung um den wichtigen Teil jedes Beispiels zu platzieren. Ein Durchgang löst zu einem anderen Durchgang auf, anstatt zwei Bildmittelpunkte blind auszurichten. "Reduce Motion" entfernt die Driftbewegung und verkürzt den Übergang, während ein Mittelzuschnitt der elegante Fallback ist, wenn keine Saliency verfügbar ist.
Warum jetzt ein Benchmark-Suite entwickelt wird?
Die Leistung einer großen Bibliothek hat ein Stadium erreicht, in dem Intuition nicht mehr ausreicht. Eine Änderung kann dazu führen, dass ein Bildschirm schneller erscheint, während gleichzeitig Importe, Erinnerungen oder Konstellationen langsamer werden, da sie alle auf die gleichen geografischen und Foto-Pipelines angewiesen sind.
Die neue Suite hat zwei Pfade:
- Eine Logik-Engine führt deterministische Funktionsprüfungen an kleinen, mittelgroßen und belastungsgesteuerten Systemen durch, einschließlich einer 82,000-Foto-Ebene, die auf dem umfangreichsten verfügbaren realen Bericht während der Entwicklung basiert.
- Eine Benutzeroberfläche zeigt repräsentative Bildschirme, während die eigene Leistungsmessung von Mapsake die Ausführungszeit, Probleme und den Speicherverbrauch aufzeichnet.
Benchmarks verwenden eine für die Veröffentlichung optimierte Version mit aktivierter Testbarkeit. Debug-Builds sind absichtlich ausgeschlossen, da nicht optimierter Swift Zahlen liefert, die für die veröffentlichte App nicht relevant sind. Simulator- und Ergebnisse von physischen Geräten werden ebenfalls separat bewertet, damit unterschiedliche Hardware nicht als die gleiche Umgebung behandelt wird.
Die Suite umfasst den Gazetteer, die Kartengeometrie, Importe, Metadaten von Fotos, Erfolge, Passport, Freunde, Backups, Stempel, Konstellationen, Erinnerungen und den Foto-Explorer. Live-Netzwerke, Kamerabitraten, System-Fotodaten und CloudKit sind weiterhin Integrationstests, da die Annahme, dass diese Eingaben deterministisch sind, zu weniger ehrlichen Ergebnissen führen würde.
Ein Benchmark kann irreführend sein.
Die Entwicklung des gesamten Pakets erforderte mehr Aufwand als das bloße Einbinden eines Stoppuhrs in den App-Code. Die erste Testumgebung verwendete eine einfache Hash-Funktion zur Auswahl der Koordinaten; Swift randomisiert diesen Hash bewusst zwischen den Prozessen, was die Geometrie-Berechnungen von etwa 30 Prozent von einem Durchlauf zum nächsten verändert. Die Testumgebungen verwenden jetzt einen festen Generator, und die Suite validiert die generierte Form, bevor ein Ergebnis akzeptiert wird.
Ein früheres Szenario namens import.merge misst neue Einfügungen. Der Produktionspfad, den es darstellen sollte, war ein idempotenter Merge in einen bestehenden Atlas. Der Benchmark war schnell und wiederholbar, testete aber das falsche. Die Korrektur der Testumgebung änderte die Basislinie, bevor Optimierungen vorgenommen wurden.
Bei den UI-Messungen zeigte sich ein ähnliches Problem. Leistungskennzahlen wurden ab dem Start erfasst, sodass eine Tab-Geste Ruckler von der Startanimation erben und langsamer erscheinen konnte, als sie tatsächlich war. Jede Interaktion löscht jetzt ihren Snapshot vor der Geste und verarbeitet dann nur die Arbeit innerhalb des jeweiligen Kontexts.
Die Laufzeit zeichnet Umgebung, Betriebssystem, Hardware-Spezifikation, Build und thermischen Zustand auf. Ein Simulationsergebnis wird niemals gegenüber einem Geräte-Basiswert bevorzugt. Nicht-normale thermische Läufe sind nützliche Diagnoseinformationen, werden aber stattdessen als Fehler gekennzeichnet, anstatt einen Regressions-Test zu verhindern. Ein Regressions-Test muss sowohl einen relativen Schwellenwert als auch einen kleinen absoluten Mindestwert überschreiten, damit Rauschen im Millisekundenbereich nicht zu einer falschen Fehlermeldung führt.
Diese Details sind nicht Teil der Bürokratie rund um den Benchmark. Sie sind das, was diese Zahl handlungsrelevant macht.
Die Korrekturmechanismen haben einen Fehler in der Karte gefunden
Der wertvollste Test im ersten Performance-Durchlauf maß nicht die Geschwindigkeit. Er verglich die optimierte Ableitung von Fotos zu Orten mit einer absichtlich einfachen, eingefrorenen Referenz über koordinatenreiche Grenzen.
Dieser Schutzmechanismus versagte, bevor die Optimierung überhaupt die Engine verändert hatte. Fotos innerhalb überlappender administrativer Polygone (Berlin innerhalb von Brandenburg, Seoul innerhalb von Gyeonggi und Kyiv innerhalb ihrer umliegenden Oblast) konnten gemäß der zufälligen Iterationsreihenfolge eines Wörterbuchs zugewiesen werden. Dieselbe Koordinate konnte nach einem Neustart unterschiedlich aufgelöst werden.
Sowohl der Referenz- als auch der Produktionsmotor ordnen überlappende Kandidaten jetzt nach Polygonfläche, sodass das spezifischste administrative Merkmal deterministisch gewinnt. Erst nachdem 82,000 Testfotos keine Unterschiede mehr erzeugten, wobei die warmen und kalten Pfade übereinstimmten, wurden die räumlichen Abkürzungen akzeptabel.
Dies ist der stille Vorteil der Leistungsoptimierung mit Äquivalenzprüfungen: Sie kann ein Korrektheitsproblem aufdecken, das eine normale Timing-Analyse niemals erkennen würde.
Was sich in den ersten Messungen geändert hat.
Der erste Stresstest deckte mehrere gemeinsame Engpässe auf. Der erste Optimierungsschritt umfasste die indizierte Geometrieerkennung, einen persistenten geografischen Zellen-Cache, memoisierten Ortsauflösung, gemeinsame Foto-Schnappschüsse und inkrementelle Atlas-Annotation-Updates.
Im Simulator reduzierte sich die anfängliche Erstellung einer 82,000-Foto-Karte von 34.5 Sekunden bis 8.0 Sekunden. Eine häufige Aktion nach einer Filteränderung oder beim Öffnen von "Orte" ist die Wiederholung, die zu 2.8 Sekunden. Die Planung von Konstellationen im Foto-Bereich von 10,000 ist fehlgeschlagen. 3.3 Sekunden bis 0.9 Sekunden. Die Tab-Wechselzeit sank um 31 Prozent, und die Passport-Pager-Fehler sanken um 47 Prozent.
Der nächste Durchgang ersetzte wiederholte SQLite-Breitenband-Scans durch einen Lazy-Breiten-sortierten Nearest-City-Index und einen begrenzten Record-Cache. Im Simulator-Benchmark sank ein mittelgroßer Nearest-City-Batch von 2.11 Sekunden bis 5.2 Millisekunden. Auf einem physischen iPhone ist derselbe gemeinsame Mechanismus fehlgeschlagen. 3.06 Sekunden bis 6.35 Millisekunden, während die Planung von Sternbildern unter Berücksichtigung der Belastungsstufe von 5.60 Sekunden bis 65.9 Millisekunden.
Diese zweite Überarbeitung hat auch die 82,000-Foto-Kaltgenerierung von 7.96 Sekunden auf etwa 1.00 Sekunden. auf dem Simulator, mit einem Warmstart bei 984 Millisekunden. Die Verbesserungen wurden erzielt, da die Suche nach der nächstgelegenen Stadt unter Imports, Then & Now, der Kartenerstellung und den Konstellationen liegt und nicht zu einem einzelnen Bildschirm gehört.
Dies sind kontrollierte Benchmark-Workloads, keine Garantie dafür, dass jedes Gerät oder jede Bibliothek die gleiche Zahl ausgibt. Ihr Wert liegt in der Vergleichbarkeit: feste Parameter, aufgezeichneter thermischer Zustand, festgelegte Ergebnisse und Mechanismen, die eine aussagekräftige Regression erkennen können.
Schneller, weil die Arbeit wiederverwendbarer wurde.
Die größten Verbesserungen kamen nicht von der Entfernung von Funktionen oder dem Hinzufügen eines Lade-Spinners. Sie kamen von der Vermeidung wiederholter Arbeit:
- Die Regionsgeometrie verengt jetzt die Kandidatenpolygonen, bevor teure Punktprüfungen durchgeführt werden.
- Ein geografischer Zellen-Cache, der an den Build gebunden ist, merkt sich gelöste Bereiche über mehrere Durchläufe hinweg.
- Die Suche nach der nächstgelegenen Stadt verwendet einen numerischen räumlichen Index anstelle einer Neuberechnung einer Datenbank-Sortierung für jede Koordinate.
- Foto-basierte Oberflächen teilen einen unveränderlichen, gefilterten Schnappschuss.
- Atlas-Markierungen und -Flaggen werden anhand der Kennung aktualisiert, anstatt alles zu entfernen und neu zu erstellen.
Der Photo Explorer und Constellations profitieren beide davon, da sie auf denselben Grundlagen aufbauen. Dies gilt auch für Imports, Then & Now, Datenkarten und Ortsgeschichten.
Der Benchmark-Code ist nicht in App Store-Archiven enthalten, aber die Praxis bleibt im Repository erhalten: Führen Sie den Test um Änderungen an einem wichtigen Bereich durch, vergleichen Sie ihn mit der korrekten Baseline und behalten Sie das Ergebnis bei. Leistung ist jetzt etwas, das das Projekt testen kann, nicht nur etwas, das es hofft zu bemerken.
Die Zahlen dokumentieren auch unvollständige Arbeiten. Eine spätere UI-Implementierung für physische Geräte erreichte einen kritischen thermischen Zustand und wies dennoch einen hohen Speicherverbrauch beim Umschalten zwischen Tabs auf und eine fast sekündliche Verzögerung beim Öffnen von Constellations im Vergleich zur echten Bibliothek auf. Diese Werte sind diagnostisch und nicht als sauberer Regressionsvergleich gedacht, aber es ist nützlicher, sie sichtbar zu lassen, als die App als "fertig" zu deklarieren.
Was diese drei Projekte gemeinsam haben.
Photo Explorer, Constellations und die Benchmark-Suite entstanden alle aus derselben Einschränkung: Eine große Foto-Bibliothek sollte nützlicher werden, ohne das Gerät zu belasten oder den Rest der App zu verlangsamen.
Photo Explorer wandelt bekannte Metadaten in Fragen und Sammlungen um. Constellations wandelt repräsentative Bilddaten in eine visuelle Geschichte um. Die Benchmark-Suite sorgt dafür, dass beide Funktionen auf die gemeinsamen zugrunde liegenden Engines abgestimmt sind.
Die Funktionalität ist in einem Suchergebnis, einem Sternenhimmel und einem Übergangsschnitt sichtbar. Die technische Umsetzung ist hauptsächlich in dem, was nicht passiert, erkennbar: Ein Upload wartet nicht, bis alle 82,000 Fotos verarbeitet sind, ein Filter erstellt nicht fünf Kopien desselben Arrays, und ein schneller räumlicher Index ändert nicht stillschweigend, zu welcher Stadt ein Foto gehört.
Das ist die Richtung, in die ich die Performance-Arbeit in Mapsake lenken möchte. Geschwindigkeit ist nicht eine Aufräumphase nach ehrgeizigen Ideen. Sie ist eines der Werkzeuge, mit denen diese Ideen sicher gehalten werden können.