Die Wissenschaft hat wieder einmal festgestellt, dass die Skript-API undokumentierte Probleme enthält. 
Erstmals sind mir bei meinen beiden Aktualisierer-Mods Verzögerungen durch den API-Skript-Befehl getNode2SegmentMap aufgefallen. Dieser Befehl liefert eine Tabelle sämtlicher Verbindungen zwischen Nodes und Edges auf einer Map. Das wird benötigt, um Streckenverläufe festzustellen, zu prüfen, wieviele Anschlüsse sich an einer Abzweigung oder Kreuzung befinden, und für noch einige andere Sachen. Das Generieren dieser riesigen Tabelle dauert relativ lange, und umso länger, je mehr Gleise und Straßen verlegt sind. Bislang habe ich in meinen Tools diese Funktion recht häufig aufgerufen, was dann immer wieder zu Lags geführt hat. Da ich eher kleinere Maps teste, ist es mir nie so sehr aufgefallen.
Das Problem lässt sich beheben, indem man getNode2SegmentMap nur dann aufruft, wenn sich etwas am Gleis- oder Straßenverlauf geändert hat oder Entities umnummeriert wurden. Während kurzer Operationen kommt das nicht vor, wenn es nicht gerade Teil der Operation selbst ist. So muss man getNode2SegmentMap nur ein einziges Mal zu Beginn einer Operation aufrufen und braucht dann nur noch Daten aus dieser Tabelle herauszugreifen, ohne sie ständig neu zu generieren. Gerade bei großen Maps mit vielen Elementen ist die Beschleunigung enorm.
Eine weitere Beschleunigungsmöglichkeit besteht noch darin, die beiden ähnlichen API-Funktionen getNode2TrackEdgeMap nur für Gleise oder getNode2StreetEdgeMap nur für Straßen zu verwenden, sofern nicht zwingend alles abgefragt werden muss. UG wird sich schon etwas dabei gedacht haben, warum es diese an sich redundanten Funktionen auch noch gibt. 
Apropos: Da es sich bei der erzeugten Tabelle um Userdata handelt, müssen die Edge-ID-Werte zu einem Node zunächst in eine Mini-Tabelle umkopiert werden (deepcopy geht auch), um erfolgreich ausgelesen zu werden. 
