[.NET] Serialization.

[Verwijderd]

Op het moment ben ik aan het uitzoeken wat de meest efficiente manier is om een server lijst op te slaan in een bestand. De server lijst bestaat uit een n aantal servers (1000, 10.000..); een server is een object ServerInfo.

Een ServerInfo object is een class dat uit ongeveer 20 fields bestaat, waarvan 2 fields arrays van de structures Player en Rule zijn..
De Rule structure bestaat uit 2 fields: string Name en string Value en de Player structure doet er nu niet toe

Nu ik een serverlijst met 1000 servers wil serializen (binary), duurt dat een eeuwigheid (~17 seconden). Wanneer ik de field Rule in de ServerInfo object niet-seriazable maak, is het serializen binnen ~70ms klaar..
Het bestand dat gegenereerd wordt is 2mb als ik de rules ook serialize.

Een server object kan een array van Rules hebben met een grootte van 60. Bij 1000 servers heb je dus, juist, 60.000 rule objecten, wat blijkbaar te veel?

Mijn vraag: Hoe kun je het best een grote server lijst opslaan in een bestand, of hoe is hetgene wat ik doe te optimaliseren?

PS. Als ik naar een ander soort gelijk programma kijk, is het bestand met de servers (binary) van ongeveer dezelfde grootte..

[Verwijderd]

Waarom sla je het niet op in Xml? In plaats van te serializen kan je dan ook simpel één enkele server ophalen.
Nog sneller is het opslaan in een database. Want met deze hoeveelheid data lijkt me dat een betere keuze.

Maar dit is natuurlijk niet direct een antwoord op je vraag .

[Verwijderd]

Als ik alles in xml zou opslaan wordt het uiteindelijke bestand erg groot, terwijl het doormiddel van binary serialization zou moeten werken.

Misschien dat het efficienter is als ik geen array van structures gebruik in het ServerInfo object, maar gewoon 1 string gebruik en daar alles in stop?

[Verwijderd]

Wat is precies je probleem? Je weet welke methodes je kan gebruiken. Wil je van ons horen welke methode jij moet gaan gebruiken? Vind je 17 seconden te lang, wil je de rules erbij hebben?

Ik zou zeggen ga voor het de binaire serialisatie. Maar vuur deze niet af in de main thread maar in een nieuwe thread. 17 seconden is namelijk wel erg lang.

XMl vind ik ook een goede methode voor een dergelijke lijst, met als enige verschil dat je dan de objecten zelf moet vullen wat waarschijnlijk te veel werk is in vergelijking met de normale serialisatie.

I'd say go for it!

CJ

[Verwijderd]

Het probleem is dat 17 seconden veel te lang is in vergelijking met een ander soortgelijk programma. Wat hun object graph is weet ik niet, maar ik weet wel dat ze ook binary serialization gebruiken en alles (incl. rules/players) kunnen opslaan naar een bestand binnen ongeveer eeen seconde.

Misschien dat het niet slim is als ik een array van structures gebruik in mijn ServerInfo object, maar er beter 1 string van kan maken die alle data bevat?

[Verwijderd]

Het probleem is dat 17 seconden veel te lang is in vergelijking met een ander soortgelijk programma. Wat hun object graph is weet ik niet, maar ik weet wel dat ze ook binary serialization gebruiken en alles (incl. rules/players) kunnen opslaan naar een bestand binnen ongeveer eeen seconde.

Gebruik een thread. Die zijn bedoeld om langdurige operaties uit te voeren en in principe onafhankelijk zijn van de andere processen.

[Verwijderd]

muhaha ik gebruik nu geen array van structures meer, maar een collection. Het verschil? zo'n 17 secondes Ogelost dus

[Woy]

Verwijderd schreef op 14 oktober 2002 @ 14:59:
muhaha ik gebruik nu geen array van structures meer, maar een collection. Het verschil? zo'n 17 secondes Ogelost dus

Dat is ook logisch als je eerst een array gebruikt die altijd lengte 60 heeft. Hierdoor moet je inderdaad 60000 velden langslopen om op te slaan. Bij een collection loop je het aantal velden langs die je ook werkelijk hebt opgeslagen. Arrays zijn eigenlijk alleen handig om te gebruiken als je precies weet hoeveel objecten je op wilt slaan en deze ook altijd gebruikt.

[Glimi]

Verwijderd schreef op 14 oktober 2002 @ 14:59:
muhaha ik gebruik nu geen array van structures meer, maar een collection. Het verschil? zo'n 17 secondes Ogelost dus

Arrays in een OO taal? [rml]Glimi in "[ C / C++] De grootte van een array"[/rml]

[Verwijderd]

rwb schreef op 14 oktober 2002 @ 18:07:
[...]


Dat is ook logisch als je eerst een array gebruikt die altijd lengte 60 heeft. Hierdoor moet je inderdaad 60000 velden langslopen om op te slaan. Bij een collection loop je het aantal velden langs die je ook werkelijk hebt opgeslagen. Arrays zijn eigenlijk alleen handig om te gebruiken als je precies weet hoeveel objecten je op wilt slaan en deze ook altijd gebruikt.

De lengte was bekend, en iedere veld had ook altijd een waarde en werd ook altijd gebruikt. Bij 1 gametype waar ik mee aan het testen was, waren er altijd ~60 rules, maar bij een ander gametype is dit waarschijnlijk anders.

[Woy]

Verwijderd schreef op 14 oktober 2002 @ 21:38:
[...]


De lengte was bekend, en iedere veld had ook altijd een waarde en werd ook altijd gebruikt. Bij 1 gametype waar ik mee aan het testen was, waren er altijd ~60 rules, maar bij een ander gametype is dit waarschijnlijk anders.

Als je altijd die 60 rules gebruikt dan snap ik niet waarom je met een ander type van de collections namespace sneller gaat. Het lijkt me dat een array sneller is als b.v. een ArrayList. Behalve als je code om de list te doorlopen anders is, lijkt mij een array sneller. Want volgens mij is een ArrayList b.v. gewoon gebaseert op een array met wat extra stukjes code om hem te kunnen gebruiken als een list. Dus weet je zeker dat je niet wat anders veranderd hebt waardoor het sneller gaat?

[Verwijderd]

rwb schreef op 14 oktober 2002 @ 22:47:
[...]


Als je altijd die 60 rules gebruikt dan snap ik niet waarom je met een ander type van de collections namespace sneller gaat. Het lijkt me dat een array sneller is als b.v. een ArrayList. Behalve als je code om de list te doorlopen anders is, lijkt mij een array sneller. Want volgens mij is een ArrayList b.v. gewoon gebaseert op een array met wat extra stukjes code om hem te kunnen gebruiken als een list. Dus weet je zeker dat je niet wat anders veranderd hebt waardoor het sneller gaat?

Wanneer ik een rule als structure toevoegde aan de collection, duurde het ook ongeveer 17 seconden. Toen ik ze niet als structure toevoegde aan de collection, maar als string (\x00 om de naam/value strings uit elkaar te kunnen houden), duurde het nog geen seconde.

[curry684]

Verwijderd schreef op 15 oktober 2002 @ 00:53:
Wanneer ik een rule als structure toevoegde aan de collection, duurde het ook ongeveer 17 seconden. Toen ik ze niet als structure toevoegde aan de collection, maar als string (\x00 om de naam/value strings uit elkaar te kunnen houden), duurde het nog geen seconde.

Lijkt me typisch zo'n bug die ze in v1.1 moeten gaan fixen, voor serialization maakt het geen kont uit of je een array of een collection gebruikt: 60000 objecten is 60000 objecten, en dat moet simpelweg binnen een seconde kunnen op een beetje systeem.

[Verwijderd]

curry684 schreef op 15 oktober 2002 @ 01:01:
[...]

Lijkt me typisch zo'n bug die ze in v1.1 moeten gaan fixen, voor serialization maakt het geen kont uit of je een array of een collection gebruikt: 60000 objecten is 60000 objecten, en dat moet simpelweg binnen een seconde kunnen op een beetje systeem.

Dat dacht ik ook, en achteraf ben ik toch blij dat ik dit maar geprobeerd heb, want echt logisch leek het me niet.

Overigens, als ik de naam/value pair niet toevoeg aan de lijst gesplitst door een '\x00', maar 'headers' gebruik voor iedere naam/value (dus als je 'hoi' wil toevoegen aan de lijst, voeg ik het toe als '3:hoi'), duurt het zo'n 7 seconden.

[curry684]

Even een schup: ik heb dit met een collega doorgesproken en we hebben waarschijnlijk bedacht wat er hier gebeurt. In .NET heeft meneer Microsoft de 'liever lui dan moe' tactiek toegepast en arrays geimplementeerd bovenop een standaard collection ipv als lijst van harde pointers. Deze collections zijn (gokken we) linked lists, wat normaliter een heel snelle tactiek is om er overheen te lopen. Echter stel nu even een loopje over items 0 tot 10 van een array op die manier voor:

code:

for i = 0 to MyArray.Size
  stream MyArray[i] into MyStream

Ieder element moet afzonderlijk opgezocht worden by index, ergo voor item 5 begint hij weer aan het begin van de list, om daarna 5 keer de nextitem op te vragen voordat ie bij de goede is. Trek dit verhaal even door, en om 10 items te streamen loop je dan dus over 1+2+3+4+5+6+7+8+9+10 items... oftewel een exponentieel probleem waarbij je niet over 1000 * 60 objecten op deze manier wil lopen

Overigens erg slecht van MS, dit kun je met intelligente last-item-caching makkelijk verhelpen tot een lineair probleempje...

[Verwijderd]

Als je het echt zeker wil weten curry moet je 't even opzoeken in de rotor source , ik ben wel benieuwd eigenlijk