246643_de-DE

liliconcom

Namespaces und Leistung benutzerdefinierter Funktionen

Beim Erstellen einer Bibliothek mit benutzerdefinierten Funktionen habe ich einen deutlichen Unterschied in der Leistung desselben Funktionscodes festgestellt, je nachdem, ob sich die Funktion im globalen Namespace oder einem benutzerdefinierten Namespace befindet. In mindestens einem meiner frustrierenden Fälle dauerte die Ausführung derselben Funktion in einem benutzerdefinierten Namespace siebenmal so lange wie im globalen Namespace.

Der Unterschied spielt in vielen Anwendungen keine Rolle, aber ich verwende diese Funktionen für Tabellen mit 500.000 bis 5 Millionen Zeilen; Ein Unterschied dieser Größenordnung macht den Unterschied zwischen einer guten und einer unbrauchbaren Funktion aus.

Hier einige JSL, die den Unterschied veranschaulichen:

Names Default to Here(1);

Add Custom Functions(
 globaltest = New Custom Function(
  "Global",
  "test123",
  Function({x, y, z},
   {a, b, c},
   a = x;
   b = y;
   c = z;
   Return(c)
  )
 )
);
Add Custom Functions(
 nstest = New Custom Function(
  "other",
  "test123",
  Function({x, y, z},
   {a, b, c},
   a = x;
   b = y;
   c = z;
   Return(c)
  )
 )
);

For(i = 1, i <= 10000, i++,
 foo = ::test123(i, i, i);
);

For(i = 1, i <= 10000, i++,
 foo = other:test123(i, i, i);
);

Auf meinem Rechner wird ::test123() in 143 ms ausgeführt, während other:test123 343 ms benötigt.

Ich habe einige Funktionen, die ich idealerweise in einem benutzerdefinierten Namespace oder als Klassenmethoden implementieren würde, aber der mit der Namespace-Qualifizierung verbundene Mehraufwand macht dies unhaltbar.

Haben andere dies bemerkt und gibt es Techniken/Überlegungen, die den Aufruf von Namespace-qualifizierten Funktionen beschleunigen können?

Betreff: Namespaces und Leistung benutzerdefinierter Funktionen

Ich werde die In-Out-Strategie einmal ausprobieren!!! Danke Craige!!!!

Betreff: Namespaces und Leistung benutzerdefinierter Funktionen

return(), break() und continue() haben alle das gleiche Verhalten. Während sie die Lesbarkeit und Wartung der JSL erleichtern, entsteht bei ihrer Ausführung ein gewisser Mehraufwand. Ich bin mir ziemlich sicher, dass der JSL-Profiler sie darauf hinweisen wird, wenn sie der Hotspot sind.

Ja, mir ist aufgefallen, dass es auch Nachteile für Namensräume gibt, aber ich bin bereit, sie für komplizierte Projekte zu verwenden. Für einfache Variablen, die sich als Hotspot erweisen, können Sie eine Ein-/Auskopierstrategie wie unten verwenden. (Zuerst Profil, optimieren Sie keinen Code, der Sie nicht ausbremst!)

Das Folgende macht fast nichts anderes, als den Namespace auszunutzen; Der meiste Code würde bei der Verwendung eines Namespace nicht so große Nachteile sehen.@EvanMcCorkle

test = New Namespace(
 "test"
);

f = Function( {},
 {i, testx},
 test:x = 0;
 If( useLocal, // speed up by copy-in, copy-out
  testx = test:x;
  For( i = 1, i < 1e6, i += 1,
   testx = testx + 1
  );
  test:x = testx;
 , // no speed up
  For( i = 1, i < 1e6, i += 1,
   test:x = test:x + 1
  );
 );
);
useLocal = 0;
t0 = Tick Seconds();
f();
t1 = Tick Seconds();
Show( useLocal, t1 - t0, test:x );//t1 - t0 = 2.76666666666642;
useLocal = 1;
t0 = Tick Seconds();
f();
t1 = Tick Seconds();
Show( useLocal, t1 - t0, test:x );//t1 - t0 = 0.316666666665697;

Betreff: Namespaces und Leistung benutzerdefinierter Funktionen

Hoppla, ich habe im Skripthandbuch auf Seite 896 einige Anmerkungen dazu gefunden. Ich hätte wissen sollen, dass ich zuerst dort nachsehen musste. Der größte Tipp scheint darin zu bestehen, Ausdrücke gegenüber Funktionen zu bevorzugen, wenn Geschwindigkeit entscheidend ist. Außerdem war mir nicht klar, dass Return()-Anweisungen die Dinge verlangsamen. Für weitere Tipps wäre ich dankbar.