• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Timer Event vs. llSleep(...)

Johanna Burnstein

Freund/in des Forums
Shirley Iuga schrieb:
(wär aber besser Thema für einen neuen Thread...)

Ich mach mal, nicht daß man mir noch Threadhijacking vorwirft... :)

Shirley Iuga schrieb:
Johanna Burnstein schrieb:
Shirley Iuga schrieb:
Soweit ich weiß verursacht ein einfaches llSleep auch weniger Lag als ein llSetTimerEvent + timer-Event + Variablenabfrage im If-loop. War zumindest in LSL2 so.

Abgesehen davon heist es ja auch das der timer event frühestens nach der angegebenen Zeit auslöst. Das kann also auch später sein, wenn sich noch andere Events im Queue davor befinden. Andererseits blockiert llSleep ja, da die Events nicht parallel abgearbeitet werden. (Brauchen sie ja auch nicht bei einer State Machine.)
Also sollte man sich sowas (bei großen Zeiträumen) vorher uberlegen, da dort ein timer Event sinnvoller ist.

Naja, die Frage bzgl. den Ressourcen ist, wie das ganze in Mono gelöst ist. Ob da nun bei llSleep ständig NOP-Operationen ausgeführt werden, oder ob das intern mit einem Timer gemacht wird.
gibts da irgendwo einen offenen Sourcecode dafür?
(wär aber besser Thema für einen neuen Thread...)

Ansonsten können im Script hier ja im pause-State keine weiteren Events aufschlagen.

Mir gings in dem Fall auch nicht so sehr um die Performance, sondern eher darum daß llSetTimerevent + timer() nicht blockieren, wärend llSleep das tut. Wenn auch Events in die Warteschlange gestellt werden, so werden diese aber erst abgearbeitet (die Handler aufgerufen) wenn llSleep fertig ist (und die Eventfunktion, in der llSleep aufgerufen wurde, zurückkehrt).

Hängt natürlich vom erwarteten Verhalten ab. IMO Gerade bei längeren Wartezeiten könnte ein langes llSleep bis auf den Benutzer durchschlagen, der dann davor steht und wie wild drauf rumklickt und sich sagt, "Warum passiert da nix!?" In so einem Fall könnte dann ein Touchevent Handler das abfangen und sage "Du, hör mal. Ich bin gerade beschäftigt, oder warte auf etwas. Komm doch später nochmal wieder."

Wie gesagt, kommt auf den Fall an. Wenn keine Interaktion mit einem Benutzer stattfindet könnte llSleep wieder besser sein, da (vieleicht) performanter, leichter zu verwenden (als die llSetTimerEvent, Timereventhandler, etc Variante), etc...

Apropos, es wird (zumindest bei LSL2) nur ein Event pro "Type" (timer, touch, etc) in die Schlange gestellt. Hatt sich das bei Mono geändert?

Und zum Thema Interne Handhabung: Kann ich nur vermuten, aber ich denke daß das eh in einem Thread des Servers läuft, der dann halt schlafen gelegt wird. Das ist oft eine Kernelfunktion, und daher vom verwendeten System abhängig. Könnte auch 'ne Bibliothek sein, aber die landen ja auch oft wieder bei den entsprechenden Kernellfunktion.

Gruß
 
Naja das kommt doch immer auf die Anwendung an,

llSleep ist eine sehr einfache Form um in einem Script eine Pause einzulegen.

Ich sehe es als eine vereinfachung vom llSetTimerevent + Timer ().

Wenn du eine so einfache Sache hast wie zum Beispiel ein Farbenwechsel bei einer Lampe alle 30 Sekunden reicht ein llSleep völlig aus
 
@ johanna:

Code:
        public void llSleep(double sec)
        {
            m_host.AddScriptLPS(1);
            Thread.Sleep((int)(sec * 1000));
        }

es ist also ein "echtes" sleep und kein NOP.
 
ich finde llSleep(); sollte man verwenden wenn das script ein pause machen soll oder still stehen soll denke ich.

und denn timer() mit llSetTimerEvent(); sollte man verwenden wenn man alle paar sek etwas auslösen möchte.

bei llSleep ruht das ganze script für eine gewisse zeit und beim timer da ist das script on und löst halt nur nach einer gewissen zeit aus.

also ich finde den timer besser :D
 
Der deutliche Nachteil beim llSleep liegt einfach darin, daß in der Zwischenzeit nichts behandelt wird - ist ok wenn es nur ganz kurze Abstände sind. Bei längeren Zeiten ist immer die Frage ob es noch irgendeineandere Funktion im Script (listener/dialog Menü o.ä.) gibt, die man blockieren würde.

Meist verwende ich Timer, und llSleep nur für kurze Verzögerungen z.B. bei Partikelsystemen.
 
Also wenn das echtes Sleep ist, dann sollte man das IMHO wohl immer da verwenden, wo ein Skript warten muss, ohne dass eine eingabe gemacht werden muss oder ohne dass da ein Event ausgelöst werden muss, einfach weil das dann deutlich ressourcenschonender ist.

Ist zwar mit Mono wohl kein so großes Thema mehr wie mit LSL, aber wenn da mal sehr viele Scripte mit timer aktiv sind, die auf irgendwas nur warten, aber dennoch weiterlaufen, dann dürfte man da möglicherweise schon einen Unterschied merken zu einer gleichen Anzahl von Scripten, die einfach nix machen, nachdem sie in einem state stehen, in dem sie nur schlafen können um dann irgendwann wieder zu wechseln in einen aktiven state.

Der Farbwechsel nach einer bestimmten Zeit ist da ein gutes Beispiel. Oder auch ein Sensor, der regelmäßig irgendwas scannt, der aber sonst keine weiteren eingaben abfragt.
 
Shirley Iuga schrieb:
Also wenn das echtes Sleep ist, dann sollte man das IMHO wohl immer da verwenden, wo ein Skript warten muss, ohne dass eine eingabe gemacht werden muss oder ohne dass da ein Event ausgelöst werden muss, einfach weil das dann deutlich ressourcenschonender ist.
Bei http://wiki.secondlife.com/wiki/LSL_Script_Efficiency heißt es dazu ungefähr:

Timer<5 sek. -> böse
llSleep -> gaaaaaanz böse!!

Ich hab das mal mit den beiden folgenden Scripten verglichen, welche im Ergebnis eigentlich genau das gleiche machen, nämlich alle 10 Sekunden 'Hallo' sagen:
Code:
default
{
    state_entry()
    {
        @ Anfang;
        llSleep(10);
        llOwnerSay("Hallo");
        jump Anfang;
    }
}
Code:
default
{
    state_entry()
    {
        llSetTimerEvent(10);
    }

    timer()
    {
        llOwnerSay("Hallo");
    }
}
Wenn ich mir die Scripttime ansehe kommt llSleep() gar nicht gut weg!

3219950115_e8bfb94cc4_o.jpg


Der Vollständigkeit halber habe ich's auch mit einer Wartezeit von 1 Sekunde getestet. timer() schneidet da mit 0.007ms tatsächlich etwas schlechter ab - aber immer noch deutlich besser als llSleep() mit 0.093ms!!!

Testumgebung: Homestead-Sim mit 1.6ms Scripttime.
 
Wenn ich mir die Scripttime ansehe kommt llSleep() gar nicht gut weg!
Rein theoretisch ließe sich das aus dem Verhalten der Script-Engine erklären. Bei Timer wird eine Zeitscheibe reserviert, das Script so lange aber "verlassen". Bei Sleep muss das Script wohl ständig aktiv sein, um zu sehen, ob es noch schläft. Sleep ist eine Zeitschleife, Timer ein Event.

So erkläre ich mir das jedenfalls.
 
Also doch nur ein NOP, was da 60s lang ständig ausgeführt wird... womit der Timer besser wär.

gibts eigentlich irgendwo eine Dokumentation der LL-Scriptengine oder sowas? Ich hab da nix finden können bisher...
 
Shirley Iuga schrieb:
Also doch nur ein NOP, was da 60s lang ständig ausgeführt wird... womit der Timer besser wär.

gibts eigentlich irgendwo eine Dokumentation der LL-Scriptengine oder sowas? Ich hab da nix finden können bisher...

nein, kein nop. thread.sleep friert den ganzen thread, also eine instanz von system.threading.thread ein und der threadhandler schaut (quasi :) ) dauernd nach welchen state nun der thread hat.
 
Sin Ronmark schrieb:
Shirley Iuga schrieb:
Also doch nur ein NOP, was da 60s lang ständig ausgeführt wird... womit der Timer besser wär.

gibts eigentlich irgendwo eine Dokumentation der LL-Scriptengine oder sowas? Ich hab da nix finden können bisher...

nein, kein nop. thread.sleep friert den ganzen thread, also eine instanz von system.threading.thread ein und der threadhandler schaut (quasi :) ) dauernd nach welchen state nun der thread hat.

hmm.. und beim timer schläft der Thread-handler oder dreht däumchen bis es Zeit ist aufzuwachen, dafür werkelt der Thread weiter?

==> LL sollte endlich mal ein Tool klarmachen, mit dem ein User, der nicht Informatik oder sowas studiert hat, sehen kann wieviele Instruktionen pro Sekunde die Skripts machen bzw. welche echte Rechenzeit sie verbrauchen...
 
nein, kein nop. thread.sleep friert den ganzen thread, also eine instanz von system.threading.thread ein und der threadhandler schaut (quasi Smile ) dauernd nach welchen state nun der thread hat.
Ja, genau das meinte ich ja. Das würde ja dann bestätigen, was ich vermutet hatte.
Das hätte dann durchaus Auswirkungen auf die Script-Time der Sim - wie es mit den physikalischen Auswirkungen aussieht... keine Ahnung, hängt davon ab, wie das gemessen wird.
 
Shirley Iuga schrieb:
hmm.. und beim timer schläft der Thread-handler oder dreht däumchen bis es Zeit ist aufzuwachen, dafür werkelt der Thread weiter?

Der schläft mit Sicherheit nicht. :) Mit Thread-Handler ist der (Betriebs-) System interne Handler/Scheduler gemeint, der reihum alle Threads, aller Processe im Systems durchgeht. (Meist Round-Robinson, d.H. Er geht reihum alle Threads durch und gibt ihnen i.d.R. 20ms Zeit um eigenen Code auszuführen *) ) Ruft nun ein Thread eine (Betriebs-) System interne Wartefunktion, wie z.B. Sleep oder eine die auf eine Mutex, Semaphore or whatever wartet, sieht das der Scheduler recht schnell (da die Ausführung eh im Kern stattfindet) überprüft schnell die Bediningung und geht dann - vor Ablauf der 20ms - zu dem nächsten Thread.

Shirley Iuga schrieb:
==> LL sollte endlich mal ein Tool klarmachen, mit dem ein User, der nicht Informatik oder sowas studiert hat, sehen kann wieviele Instruktionen pro Sekunde die Skripts machen bzw. welche echte Rechenzeit sie verbrauchen...
Ich denke das Problem daran ist einfach daß das ganze nicht so trivial ist wie es scheint, und von daher eine "einfache" Angabe wie soundsoviel IPS nicht wirklich etwas über die währe Belastung, die ein Script verursacht, ausagt.


*) ...und nein, es bringt gar nichts an der Zeitscheibe rumzufummel, das System wird dadurch nicht schneller! ;) SCNR

Nachtrag: Neben fair-queuing Schedulern können aber auch andere zum Einsatz kommen. Staircase-Deadline, Fair-Share (wie der in Linux verwendete CFS), etc. Das ist aber dann OS Philosophie, kombiniert mit viel Herzblut & Voodoo ;)
 
Joshua Philgarlic schrieb:

Das mit den "Top Scripts" funktioniert nur wenn man eine eigene Sim hat oder?

Da ich selbst scripte würde mich persönlich auch interessieren wie effizient meine Scripte sind, schliesslich will ich den Kunden keine Lagschleudern andrehen... :D
Hab ich irgendeine Möglichkeit das zu überprüfen ohne mir eine Sim zu kaufen?
 
Das nervt mich auch mit den Estate Rechten,
warum kann ich als Scripter nicht auf die vorhandenen
Performance Ressourcen zugreifen, dann könnte man schön
optimieren und das Grid würde entlastet.

Wieder LLL :D <- LindenLabLogik
 

Users who are viewing this thread

Zurück
Oben Unten