Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Lagreduzierung: Der schwächste fliegt - oder doch nicht?
#11
Meine Erfahrung mit Skripten in os ist. Alle Funktionen die Ereignisbedingt aktiviert werden, wie Sit, llListen,Touch …   sind  relativ harmlos, da sie meistens „schlafen“. Was man aber unbedingt im Auge behalten sollte sind die Timer Funktionen. Die werden periodisch durchgeführt. Hat man zu viele, gerät alles schnell aus den Fugen, weil die  irgendwann nicht mehr in eine Zeitscheibe passen. Blöder Weise braucht man den Timer aber auch für extrem viele Sachen und einen Ersatz gibt es leider nicht.  Wenn möglich, sollte man ihn daher an eine Ereignisfunktion koppeln. Beispiel, ein Avatar soll mit Namen begrüßt werden. Dann wäre es am Serverfreundlichsten man lässt den Ava auf ein unsichtbares Prim latschen, wodurch das Ereignis, Kollision eintritt und das aktiviert dann erst den Timergesteuerten Sensor um herauszufinden wer es ist. Später wird der Sensor/Timer wieder abgeschaltet. Oder man benutzt einen Timer zentral und schickt die Infos per Regionssay an die Objekte, die erst aktiv werden, wenn Daten auf ihrem Kanal anliegen.

Zum Thema Mesh und Flächenbegrenzung, das ist alles furchtbar theoretisch. Ich habe mir für mich  folgende Methode überlegt. Die Engine wurde Jahrelang auf Prims u. Sculptprims getrimmt.
Wenn ich etwas als Mesh baue überlege ich wie viele Sculptprims ich brauchen würde und addiere die Flächen. Dann habe ich eine Bezugsgröße.
Beispiel, ein verspielter Jugendstil Sessel. Das wären über den Daumen 2 Lehnen, zwei Lehnenträger, Stuhlrumpf, Stuhlrückenlehne,zwei Kissen für Hintern und Rücken, vier Beine und vier Querstreben = 16 Objekte x 1024 Dreieckflächen = 16.384 Dreiecke, wenn er mit Sculptprims gebaut würde. Wenn ich das mit meinem Mesh Sessel spürbar unterbiete ist alles im grünen Bereich Wink
Degolburg:
24h online und ca. 12% fertig
Taxi:85.214.150.139:9000:degolburg
Antworten }
Thanks given by: Achim
#12
(05.06.2017, 17:50)MoniTill schrieb: Meine Erfahrung mit Skripten in os ist. Alle Funktionen die Ereignisbedingt aktiviert werden, wie Sit, llListen,Touch …   sind  relativ harmlos, da sie meistens „schlafen“. Was man aber unbedingt im Auge behalten sollte sind die Timer Funktionen. Die werden periodisch durchgeführt. Hat man zu viele, gerät alles schnell aus den Fugen, weil die  irgendwann nicht mehr in eine Zeitscheibe passen. Blöder Weise braucht man den Timer aber auch für extrem viele Sachen und einen Ersatz gibt es leider nicht.  Wenn möglich, sollte man ihn daher an eine Ereignisfunktion koppeln. Beispiel, ein Avatar soll mit Namen begrüßt werden. Dann wäre es am Serverfreundlichsten man lässt den Ava auf ein unsichtbares Prim latschen, wodurch das Ereignis, Kollision eintritt und das aktiviert dann erst den Timergesteuerten Sensor um herauszufinden wer es ist. Später wird der Sensor/Timer wieder abgeschaltet. Oder man benutzt einen Timer zentral und schickt die Infos per Regionssay an die Objekte, die erst aktiv werden, wenn Daten auf ihrem Kanal anliegen.

Zum Thema Mesh und Flächenbegrenzung, das ist alles furchtbar theoretisch. Ich habe mir für mich  folgende Methode überlegt. Die Engine wurde Jahrelang auf Prims u. Sculptprims getrimmt.
Wenn ich etwas als Mesh baue überlege ich wie viele Sculptprims ich brauchen würde und addiere die Flächen. Dann habe ich eine Bezugsgröße.
Beispiel, ein verspielter Jugendstil Sessel. Das wären über den Daumen 2 Lehnen, zwei Lehnenträger, Stuhlrumpf, Stuhlrückenlehne,zwei Kissen für Hintern und Rücken, vier Beine und vier Querstreben = 16 Objekte x 1024 Dreieckflächen = 16.384 Dreiecke, wenn er mit Sculptprims gebaut würde. Wenn ich das mit meinem Mesh Sessel spürbar unterbiete ist alles im grünen Bereich Wink

Liebe Moni ich halte auch Befehle wie llListen für suboptimal, da ich dafür einen aktiven Listener ständig brauche. Dieser muss ja ständig lauschen ob was für ihn kommt.

Ich versuche diese Befehle einzusparen indem ich den Kommunikationsbedarf im Linkset minimiere, also so wenig Scripte wie Möglich pro Objekt einsetzte und diese dann auch alle im Rootprim unterbringe. Childprims kann man dann immer noch über Befehle wie llSetLinkPrimitiveParams "remote" manipulieren.

Auch Kollisions Objekte müssen ja ständig auf Kollision geprüft werden, wenn auch nicht von uns Scritptern selbst.

Ich denke es gibt keinen Königsweg der bei allen Scripten passt, daher muss man sehr stark Fallbezogen entscheiden was am besten geeignet ist.

Ist zum Beispiel die gewünschte Funktion in einen passiven (Warten) Zustand und einen (oder mehreren) aktiver Interaktions Zustand trennbar so arbeite ich mit mehreren "State" zuständen. So kann man die Last des Scriptes immer dann reduzieren wenn es nicht gebraucht wird. Als Kriterium könnte man einen generellen Simweiten Detector nutzen ob jemand in der Sim ist- und dann alle Scripte wecken - oder schlafen schicken.
Aber das ist nur eine Möglichkeit unter Vielen.

Eine effizientere Methode Scripte zu sparen habe ich darin gefunden gleichartige Aufgaben aus mehreren Prims zusammenzufassen, und die betroffenen Prims zu einem Linkset zu koppeln.
Beispiel 20 anrollende Wellen an der Strandlinie, oder viele gesteuerte Schnee Partikel Emitter über der Sim. Da kann ich dann mit einem einzigen Script und Befehlen wie llSetLinkPrimitiveParams zum Beispiel alle child Prims des Linksets in einem Rutsch abdecken, und behalte trotzdem die volle Veränderbarkeit des Scriptes.

Sehr Lasthaltig sind Scripte die ein Objekt stufenweise in einer Programmschleife verändern, wie zum Beispiel ein Objekt langsam unsichtbar machen. Schafft man es dafür Partikel einsetzten zu können, so kann man Start Alphs und End Alpha in der Partikelerzeugung gut dafür einsetzten.

Und ob Timer oder Wait ist vor allem eine Frage der Häufigkeit der Events. Meine Beobachtung ist folgende: Timer sind besser wenn Sachen sehr selten passieren (ca. > 10 Sekunden). Wait scheint für häufige sehr kurze Wartezeiten im Vorteil zu sein. Dabei darf man sich aber nicht auf die Regionconsole verlassen. Die scheint Waits generell zu bestrafen, was aber nach meinen Tests nicht der realen Last entspricht.
Ich habe versucht ein Objekt ohne es "physisch" zu machen, ruckfrei zu bewegen - also mit ca. 25 frames pro sekunde in kleinen Schritten. Mit wait ging das sanft -wenn auch mit messbarer Last. Die Wartepausen mit Timer zu überbrücken war hingegen ein Misserfolg. Es ruckte sehr stark, und die Last war sehr hoch. Daher vermute ich das der Wait Befehl ein Stop Befehl dasrstellt, der das Script anhält, aber geladen beläßt. Der Timer hingegen wir in Interrupt zu sehen ist der das script im Prozessor entläd und läd. Und diese Ladecyclen machen dann offenbar die meiste Last. Seither setzte ich Timer nur noch für größere Warteperioden ein.

Generell muss man sich aber fragen was man eigentlich optimieren will:

1. - die Script CPU Last auf dem Server
2. - den Script Speicherverbrauch auf dem Server
3. - den Ablauf innerhalb eines Scriptes um zum Beispiel ein Fahrzeug sanft ruckfrei und schnell bewegen zu können.

In den oberen Passagen haben wir nur über 1. und 2. gesprochen

Für einen Besucher Inworld ist aber alleine 3. entscheidend solange die zu hohe Serverlast nicht bei ihm sichtbar und fühlbar wird.

und um 3. zu optimieren muss man sich schon schon auf Prozessor befehls Ebene hinunter begeben, und wissen welcher CPU Code wieviele CPU Schritte benötigt - und welcher Befehl wie in CPU Code umgesetzt wird. Leider ist dazu rein gar nichts veröffentlicht.

Das eine Variable++ das gleiche wie Variable = Variable +1 ergibt ist noch einsehbar. Aber ersterer Befehl ist deutlich effizienter da nur ein Register geladen werden muss und ein Increment Befehl auf allen CPUs in einem Takt erledigt ist. Die Zweite Variante hingegen läd 2 Register und führt eine Addition durch. Ja das ist Kleinvieh - aber auch das macht Mist.

Bei Fahrzeug Scripten kommt es vor allem darauf an das die ständig zu durchlaufende Fahr Steuerungs Schleife so wenig Zeit braucht wie möglich, sonst ruckt es. Die Mittel dazu sind:

- Verzicht auf überflüssige Abfragen
- Verzicht auf entbehrliche periodische Ausgaben ( Die Geschwindigkeit in jeder Schleife zu ermitteln und mit floatText auszugeben kann schon reichen das das Fahrvergnügen dahin ist). Notfalls Periode der Ausgabe duch incrementierenden Zähler minimieren, zum Beispiel nur jede 100. Schleife Geschwindigkeit anzeigen
- Befehle zu verwenden die mit 200ms Strafzeit belegt sind ist fatal.
           siehe:  http://wiki.secondlife.com/wiki/LlSetLin...tiveParams
  daher nur die "fast" Befehle verwenden wie llSetLinkPrimitiveParamsFast
- In der FahrSchleife hat nichts Entbehrliches drin zu suchen was ich davor auch erledigen kann, wie Variablen deklarieren, Startwerte zuweisen, statische Berechnungen durchführen, etc. Kann man Teile der Berechnungen "vorher" erledigen so sollte man das auch tun und mit dem Teilergebnis in der Schleife operieren.
- keine Listen Befehle an Reifen etc. absetzten sondern Linkset Befehle verwenden
- statt drehende oder bewegte Objekte Texturanimation geschickt einsetzten
- keine Timer einsetzten das diese wie ein Interrupt zur unmittelbaren Unterbrechung an beliebiger Scritpstelle führen.

Naja und wer jetzt Blut geleckt hat auf ein performantes Boot Script der besuche uns in Nextlife-World. Dort gibt es diese Boote auf der Isla Bonita als Freebee.
Antworten }
Thanks given by: Achim , Bink


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste