• 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.

Welche Art des Speichern in eine Liste ist vorzuziehen?

Sarah Lunardi

Freund/in des Forums
Oft kommt es ja vor das man mehrere Informationen in eine Liste speichern möchte, in diesem Fall ist die Frage auf welche Weise man es macht. Pro Information ein Item oder lieber alles in ein Item und dann per Seperator später wieder bei der Ausgabe separieren. Wie das alles funktioniert ist klar, aber ich frag mich ob es Speicher/Leistungstechnisch einen Unterschied macht.

1.StridedList sehen so aus:
["Sarah","weiblich","170","Hans","männlich","190"]


2.Normale Listen die man separiert so:
["Sarah:weiblich:170","Hans:männlich:190"]


3.Es wäre auch möglich für jede Wertart (Name, Geschlecht, Größe) eine eigene Liste zu erstellen und die Synchron anzusprechen und anzusteuern.

Nur meine Frage ist, unterscheiden die sich überhaupt bei der Leistung (Latenz), Speicherverbrauch (Memory)?
Wenn nicht kann man ja weiterhin die nehmen die gerade am besten passt.
 
Zuletzt bearbeitet:

Takeshi Newman

Freund/in des Forums
Ich denke wenn du auf den Speicher achten musst, ist die erste oder dritte Variante vorzuziehen.
Die Listen allgemein werden sich nicht groß unterscheiden aber das auswerten der Daten benötigt in der zweiten Variante immer extra Variablen, du must einen Teil der Liste auslesen und dann noch zerlegen. Das gibt spitzen im Speicherbedarf und wenn es knapp ist, kann das das aus bedeuten. Wenn du später mal erweitern möchtest ohne das ganze script umbauen zu müssen, würde ich auf variante 3 setzten, dort könntest du einfacher das Alter oder einen Wert in eine neue Liste ablegen.
 

Rebekka Revnik

Superstar
Ich bevorzuge auch Nummer drei, weil das Ändern einer Liste immer eine Kopie derselben erzeugt, also brauchst du zum Bearbeiten immer den doppelten Speicherplatz als die Liste eigentlich hat. Der wird zwar hinterher wieder frei aber erst mal muss er da sein. Wenn du nur eine Liste verwendest und die lang genug ist und noch bissel was im Skript steht -> stack-heap collision.
 

Daemonika Nightfire

Forumsgott/göttin
@ Sarah

Schau dir mal folgende Wiki an: LSL Script Memory - Second Life Wiki
Dort wird sehr genau aufgedroeselt wie sich der Speicher im einzelnen verhaelt, dabei wird auch unterschieden ob die Variabeln Global angelegt, oder direkt im eigentlichen Script verwendet werden.
Ich habe die erfahrung gemacht, das sich lange Listen dort am besten bewert haben, wo sie gebraucht werden, solange ich sie nicht auch noch in einem anderen Event benoetige. Also erst wenn ich die selbe Variable in 2 Events benoetige, lege ich sie Global an.

LG
Dae
 

Sarah Lunardi

Freund/in des Forums
Ich bevorzuge auch Nummer drei, weil das Ändern einer Liste immer eine Kopie derselben erzeugt, also brauchst du zum Bearbeiten immer den doppelten Speicherplatz als die Liste eigentlich hat. Der wird zwar hinterher wieder frei aber erst mal muss er da sein. Wenn du nur eine Liste verwendest und die lang genug ist und noch bissel was im Skript steht -> stack-heap collision.
Soweit wie ich gelesen habe kann eine Liste ja unendlich Informationen aufnehmen bis der Speicher voll ist. Entsprechend würde der Script doch auch bei deiner Wahl an der gleichen Datenmänge auf den Limit stoßen, oder?

Momentan hab ich aber eh ein neues Problem und grübel nun auch dazu, welche Liste sich am besten eignet. Erste und zweitere Variante sind sehr gut, wenn man eine Liste sortieren möchte. Die Dritte ist wesentlich aufwendiger synchron zu halten. (da würde mir nur eine Strided-List einfallen mit einem Zusatz-Item das die Position in der Liste angibt, um so Bewegungen und Veränderungen in der Liste wahrnehmen zu können und diese auf andere Listen zu übertragen)

Auch muss ich jetzt dazu noch überlegen wie eine temporäre Liste erstelle, die automatisch alle Index-Nummern listet (auf meinem Beispiel übertragen) welche im Datensatz z.b. gezielt eine Größe oder Geschlecht "weiblich" beinhalten.

Irgendwie mögen mich Listen genauso wenig, wie ich sie.
 

Shirley Iuga

Forumsgott/göttin
Beim Speicherverbrauch von Listen kommt es immer drauf an ob man nun Mono oder LSO nutzt. Und bei Mono kommt es noch drauf an wann und wie man mit den Listen arbeitet.

Bei LSO ist das einfach, da belegen Heap and Stack zusammen einen 16kB Block und wenn da was zu groß werden sollte treffen die sich in der Mitte des Speicherbereichs und es gibt die besagt Stack-Heap Collision. Das liegt u.a. auch daran, dass LSO nicht wirklich kompiliert wird, sondern einfach über einen Interpreter in einer VM läuft.

SL Mono benutzt dagegen keine festen 64kB Blöcke sondern ein von LL bzw. Babbage Linden entwickeltes Microthreading (über .net Reflections, RAIL usw.), d.h. im wesentlichen wird der Bytecode und der Stack eben nicht wie bei LSO als homogener Block gespeichert (der dadurch leicht eine Collision erzeugen kann), Heap und Stack liegt bei SL (Mono) in voneinander unabhängigen Speicherbereichen vor, wobei in den Bytecode beim Kompilieren auch noch Stoppcodes zwischen Loops und Funktionsaufrufen eingebaut werden, an denen ein Script einfach angehalten werden kann.

In diesem angehaltenen Zustand kann das Script dann z.B. serialisiert werden: der gültige Stack wird in ein Heap Objekt kopiert und das Ganze Skript geht dann als Datenstrom an einen anderen Simulator, wo es dann wieder in die dortige VM "eingebaut" wird indem aus dem Heap Objekt wieder ein Stack im Speicher generiert wird.
Gleichzeitig sind diese gelegentlichen Break Points im Bytecode auch der Zeitpunkt, an dem die VM die tatsächliche Speicherbelegung des Scripts überprüft und das Script dann einfach anhält, wenn das "Hard Limit" (das eher "max Limit" heißen sollte) überschritten ist. (Was dann in SL zu einem Script Fehler führt, wie die Stack-Heap Collision) Dass die Speicherbelegung nur immer wieder mal überprüft wird (und nicht ständig überwacht oder im voraus abgeschätzt) führt aber auch dazu, dass ein Mono Script tatsächlich ein vielfaches der 64kB (oder der per llSetMemoryLimit() kleiner begrenzten Menge) belegen kann, z.B. bei Operationen mit langen Listen - der "zu viel belegte" Speicher muss nur bereits wieder freigegeben (bzw. "ungültig") sein, wenn ein neuer Abgleich der Speicher Allocation mit dem eingestellten Hard Limit an einem Break Point erfolgt. (siehe http://www.langnetsymposium.com/2009/talks/17-JimPurbrick-SecondLife.html ab 13:00 etwa)

D.h. lange Listen sind bei Mono, das den Speicher weniger strikt limitiert, oft nicht mehr wirklich so problematisch wie bei den LSO scripten, bei denen es schlicht unmöglich war die 16kB Grenze zu überschreiten. Vorausgesetzt, man schreibt den Code so, dass man jeweils kurze Listen-Operationen hat.
 

Jan Hird

Aktiver Nutzer
Moin Leute

Einfaches ausprobieren ergibt folgendes:

1. Strided list 2520 Records
2. Strings 1480 Records
3. Drei Listen 2520 Records

Jeweils abwechselnd die beiden Records gespeichert, das Geschlecht wurde mit "w","m" abgekürzt.
Alter wurde bei 1. und 3. als int gespeichert. Ausgabe alle 40 Records.

Spasseshalber ohne Mono:
3. Drei Listen 240 Records

bis denne
Jan
 

Aktive User in diesem Thread

Oben Unten