Riesige Verlangsamung beim Ausführen von Lua als statisch verknüpfte Bibliothek im Vergleich zum eigenständigen Interpreter

Ich entwickle einige Algorithmen in Lua, die hauptsächlich in Lua ausgeführt werden (wenige Aufrufe von C ++), und ich bemerke eine enorme Verlangsamung, wenn ich sie über meine App und nicht über den Standard-Lua-Interpreter ausführe. Das Skript kehrt mit dem Interpreter in ungefähr 11 Sekunden und mit meinem Programm in ungefähr 5+ Minuten zurück .

Ich denke nicht, dass es ein Problem beim Aufrufen der C ++ - Funktion ist. Das Überschreiben dieser Funktion mit einer leeren Funktion im Skript hat keine merklichen Auswirkungen auf die Zeit.

Sowohl Lua als auch das Programm werden mit Visual Studio 2010 kompiliert (ich habe eine neue Lösung für Lua erstellt, mit Projekten sowohl für den Interpreter als auch für die statische Bibliothek).

Ich habe einen Profiler für den Code ausgeführt (der Very Sleepy-Profiler kann einen Lua-Profiler nicht zum Laufen bringen, habe aber nicht zu viel versucht) und festgestellt, dass in meiner Anwendung etwa 50% der Zeit für malloc .. und 40% kostenlos, beide vom Lua-Garbage-Collector aufgerufen (versucht, dies zu deaktivieren, um dies zu überprüfen, aber das stürzt ab, wenn zu viel Speicher verwendet wird (verständlicherweise). Der Lua-Interpreter überprüft die RAM-Auslastung von ca. 4 MB).

Ich bin neu bei Lua, also ist es sehr wahrscheinlich, dass ich irgendwo etwas falsch gemacht habe. Hat jemand ein paar Tipps zum Ausprobieren?

c++ lua

— Elva
quelle

malloc! Die Wurzel allen Übels! Wir sind bei der ersten Untersuchung von Lua auf ein ähnliches Problem gestoßen und haben die Bemühungen einfach aufgegeben. Ich bin gespannt, ob es eine Lösung gibt.

— Crashworks

Gab es nicht einen Vorschlag, den Standard-Speicherhandler für lua in einen zu ändern, der realloc verwendet? Wenn ich mich richtig erinnere, wurde gesagt, dass dies in einigen Fällen viel schneller ist. Aber das war vor ~ 3 Jahren. Wie bindest du Lua? Wenn Sie Luabind verwenden, mit Ausnahme eines erheblichen Funktionsaufrufaufwands im Vergleich zu direkt bindenden Methoden oder wahrscheinlich auch im Vergleich zu Lua.

— LearnCocos2D

Haben Sie die Empfehlungen zur Optimierung der GC von lua ausprobiert? lua-users.org/wiki/OptimisingGarbageCollection

— David Young

@ DavidYoung Ich habe versucht, es ein bisschen zu optimieren, habe es auf beiden ungefähr 15% schneller bekommen, also nichts, was den großen Unterschied in der Geschwindigkeit wirklich erklären würde

— Elva

@GamingHorror Rückblickend auf die Call-Stacks scheint es, dass Malloc von Realloc (luaV_execute-> luaM_realloc _-> l_alloc-> Realloc-> Malloc) aufgerufen wird. Ich verwende auch die Lua C-API direkt mit ein wenig leichten Benutzerdaten für die eine Klasse, die aufgerufen werden muss.

— Elva

Wie Sie sagen, macht Lua Speicherzuweisungen standardmäßig wie verrückt. Sie sollten in Betracht ziehen , einen benutzerdefinierten Allokator zu schreiben , der die von Ihren Lua-Programmen normalerweise verwendeten Allokationsmuster besser kennt , oder etwas wie tcmalloc einstecken, um eine rundum bessere Allokationsleistung zu erzielen.

Ich habe das versucht, es spart ein bisschen Zeit (ein paar Sekunden, immer noch nicht in der Nähe des Standalone-Interpreters). Vielleicht ist das Problem (oder einer von ihnen), dass die Zuweisungszeit nicht konstant ist und davon abhängt, wie viel Speicher vorhanden ist war schon mal reserviert? Das wäre lösbar, wenn ein Speicherpool nur für Lua verwendet würde. Ich werde es versuchen (hat jemand ein paar Hinweise zur Implementierung?).

— Elva

Was spart ein paar Sekunden, tcmalloc? Der Grund, warum malloc im Allgemeinen langsam ist, liegt nicht darin, dass die Zuweisungszeit nicht konstant ist (obwohl dies häufig nicht der Fall ist), sondern darin, dass die Zuweisung eine schreckliche Cache-Lokalität, viel Sperraufwand, jede Menge Konsistenzprüfungen in Debug-Builds usw. aufweist. Grundsätzlich sollten Sie dies tun Rufen Sie während der Skriptausführung niemals echtes Malloc (und vor allem nicht wirklich kostenlos!) auf - verwenden Sie immer einen vorhandenen Speicherpool, so viel Sie können.