[C#] Object conversie performance

[Verwijderd]

Beste Tweakers,

Ik zit met een vreemd probleem. Ik deserialiseer een object collectie met 3000 objecten in minder dan een halve seconde. In die tijd is dus met file IO een XML file opgepakt en weer omgezet naar een object met een List van objecten.

Nu moet ik deze lijst op een gegeven moment omzetten naar een lijst met net iets andere objecten. Pseudo voorbeeld:

code:

public static AndereObjecten VertaalLijst(List<BronObjecten> bron)
{
  List<AndereObjecten> resultaat = new List<AndereObjecten>();
  bron.ForEach(obj=>resultaat.Add(new AndereObjecten(){waardeA=bron.WaardeC,waardeB=bron.WaardeQ});
  return resultaat;
}

En wat schetsts mijn verbazing..., dit duurt gewoon bijna 3 seconde! De typen over te zetten properties zijn gelijk, dus als waardeA = string dan in bron.WaardeC dat ook.

C# kan dus wel in een halve seconde via file IO een gedeserialiseerd bestand weer omzetten naar een object met 3000 objecten maar kan niet - in memory - een bron lijst met 3000 objecten omzetten naar een iets andere bron lijst met 3000 objecten.

Dat lijkt mij sterk... dus is de kans meestal groot aanwezig dat ik iets fout doe.

Hebben jullie enig idee wat de fout kan zijn of wat ik hier beter zou kunnen doen? Een zoekwoord tip zou ook mooi zijn, als ik op "Object conversion" zoek dan krijg ik nogal niet relevante links en ook andere zoek trefwoorden lopen nogal op andere resultaten uit.

[bigbeng]

Ik neem aan dat je een typo hebt gemaakt en dat waardeA=bron.WaardeC,waardeB=bron.WaardeQ eigenlijk waardeA=obj.WaardeC,waardeB=obj.WaardeQ moet zijn.

Hoe lees je de lijst in vanuit file?

[Haan]

Je zou in ieder geval kunnen beginnen met de List<AndereObjecten> direct de juiste grootte te geven, dus:

C#:

List<AndereObjecten> resultaat = new List<AndereObjecten>(bron.Count);

Nu moet de list steeds vergroot worden, wat natuurlijk tijd kost.

[Face_-_LeSS]

Hoe meet je de tijd? Zo?

C#:

DateTime start = DateTime.Now
var lijst = VertaalLijst(bron);
Debug.WriteLine(DateTime.Now - start);

[Haan]

Face_-_LeSS schreef op maandag 16 augustus 2010 @ 15:01:
Hoe meet je de tijd? Zo?

C#:

DateTime start = DateTime.Now
var lijst = VertaalLijst(bron);
Debug.WriteLine(DateTime.Now - start);

Ik mag hopen dat het iets is als dit:

C#:

var sw = Stopwatch.StartNew();
// process here
sw.Stop();
var elapsed = sw.Elapsed.TotalMilliseconds;

Daarbij schijnt je ook altijd in release mode en niet vanuit visual studio (dus de exe los draaien) te moeten benchen

[creator1988]

Verdeel sowieso je logica over meer stappen, dan kan je daarover gaan timen (dus het toevoegen aan de lijst, constructor aanroepen en properties setten los).

3.000 objecten in 3 seconden is overigens allesbehalve snel.

[Verwijderd]

Bedankt voor de snelle reacties. Het probleem viel op toen een step over in debug mode erg lang duurde. Daarna inderdaad met de stopwatch methode gezien dat dit 2 tot wel 3 seconde in beslag nam wat gewoon veel te lang is.

Ik heb inderdaad in plaats van een list ook al een array met benoemd maximum gebruikt maar dat gaf niet echt een groot verschil (paar miliseconde). Ik ben nu de .ConvertAll methode aan het proberen maar heb zo'n voorgevoel dat dit ook weinig uit gaat maken.

De waarde had ik even als voorbeeld, het gaat er om dat ik vanuit een bron een bepaalde propertynaam overzet naar een doel object waar de property anders heet maar wel van hetzelfde type is.

Het lijkt nu haast sneller door de collectie te serializeren naar een bestand, daar een replace te doen van de property tags naar de nieuwe tags en die terug te deserialiseren.

Het deserialiseren doe ik als:

code:

        public static object DeSerializeObject(string Xml, System.Type ObjType)
        {
            object obj;
            XmlSerializer ser = new XmlSerializer(ObjType);
            using (StringReader stringReader = new StringReader(Xml))
            {
                using (XmlTextReader xmlReader = new XmlTextReader(stringReader))
                {
                    obj = ser.Deserialize(xmlReader);
                }
            }
            return obj;
        }

Waar de ingaande xml een geserialiseerde string is die met een streamreader.readtoend eerder is uitgelezen. Dat gaat echt enorm snel en kan nog sneller door in plaats van xml serialisatie / deserialisatie de binaire serialize / deserialize te gebruiken.

[Haan]

Beetje offtopic, maar wist je dat jouw deserialize methode ook anders (imo mooier) kan?

C#:

XDocument sourceXml = XDocument.Parse(content);
XmlSerializer serializer = new XmlSerializer(typeof(myType));
XmlReader reader = sourceXml.CreateReader();

var results = (myType)serializer.Deserialize(reader);

[Verwijderd]

@Haan, tnx, altijd leuk om dit soort dingen te leren.

[HMS]

Misschien zoiets? (Als de volgorde van de objecten uitmaakt moet je AsParallel() weghalen uiteraard.

En de return is een IEnumerable<AndereObjecten>.

C#:

public static AndereObjecten VertaalLijst(IList<BronObjecten> bron)
{
  var result = from x in bron.AsParallel()
                   select new AndereObjecten { waardeA = x.WaardeC, waardeB = x.WaardeQ };
  
  return result;
}

[ Voor 0% gewijzigd door HMS op 16-08-2010 15:29 . Reden: Foutje in code. ]

[pedorus]

Waarom geen explicit/implicit cast definiëren en ConvertAll(obj=>(AndereObjecten)obj) gebruiken? Verder, gebeurd er misschien iets geks in de properties? 3000 objecten converteren lijkt me een aantal milliseconden moeten duren, niet seconden (of ze moeten wel erg groot zijn). Meerdere draadjes gebruiken lijkt me redelijk overdreven in de meeste gevallen..

[BM]

Wel handig om er dan bij te vermelden dat daar .Net 4.0 voor vereist is
Iig zolang je AsParallel gebruikt.

[HMS]

BM schreef op maandag 16 augustus 2010 @ 15:47:
Wel handig om er dan bij te vermelden dat daar .Net 4.0 voor vereist is
Iig zolang je AsParallel gebruikt.

Owh sorry, ik wist niet dat PLINQ queries .NET 4 specific waren. Maar goed, weet ik dat ook weer

@ pedorus, maar het kan wel ;-).

edit:

Wat ook nog kan, is dat er een soort lazy loading plaats vind van de XML? (Gebruik nooit (de)serialization, maar zou wel de lange access time kunnen verklaren.)

[ Voor 24% gewijzigd door HMS op 16-08-2010 15:53 ]

[BugBoy]

Er is echt iets anders aan de hand als het serializen / deserializen sneller gaat dan een rechtstreekse omzetting van de objecten. Veel sneller dan onderstaande code zul je het niet gaan krijgen (zonder de code parallel uit te voeren):

C#:

public static IList<AndereObjecten> VertaalLijst(IList<BronObjecten> bron)
{
  var resultaat = new AndereObjecten[bron.Count];
  for (int index=0; index<bron.Count; ++index)
  {
    resultaat[index] = new AndereObjecten()
        {
          waardeA = bron[index].WaardeC,
          waardeB = bron[index].WaardeQ
        };
  }
  return resultaat;
}

Offtopic: Ik zou altijd met interfaces werken, omdat je zo meer vrijheid houdt om de interne implementatie aan te passen en je methode wordt breder bruikbaar (mijn implementatie accepteert ook een array i.p.v. een lijst). Als je persé een echte lijst wil teruggeven, dan moet de lijst initialiseren met de gewenste lengte.

[Korben]

BugBoy schreef op maandag 16 augustus 2010 @ 23:55:
Offtopic: Ik zou altijd met interfaces werken, omdat je zo meer vrijheid houdt om de interne implementatie aan te passen en je methode wordt breder bruikbaar (mijn implementatie accepteert ook een array i.p.v. een lijst). Als je persé een echte lijst wil teruggeven, dan moet de lijst initialiseren met de gewenste lengte.

Met je principe ben ik het zeker eens, programmeer tegen interfaces. Echter, als jouw functie een IList<T> accepteert kun je er wel een array aan meegeven, maar vervolgens functioneert die array niet als een volwaardige IList<T> (je kunt hem bijvoorbeeld niet bewerken). Ik zou eerder kijken naar IEnumerable<T> als argument en als returntype. Hetzelfde gaat daar namelijk voor op; in de meeste gevallen hoef je alleen maar over die resultaten heen te enumereren, dus is het helemaal niet interessant of het wordt opgeslagen in een lijst of een array of een LinkedList<T>, enzovoorts.

[Verwijderd]

Mooi om dit allemaal te lezen er er van te leren. Ik kreeg de "AsParallel" optie al niet aan de slag (heb ook geen 4.0) maar zonder AsParallel doet hij het ook. Ik moet nog testen of het sneller is.

De ConvertAll ben ik ook nog mee bezig. Lazy loading is helaas geen optie, het is juist belangrijk dat ik alle gegevens in één keer heb. Het wordt namelijk gebruikt om veelvoudinge connecties terug naar de database te voorkomen.

Het voorbeeld van BugBoy leek mij ook haast niet sneller te kunnen. Ik zal nog eens goed alle property waarden controleren en eens kijken of het met 100 objecten ook zo traag is.

Ik gebruik verderop in de code de List specifieke eigenschappen, er gaat ook zeker weten altijd een List in, maar je hebt gelijk, het is netter om een IList of IEnumerable te gebruiken. Ik zal het aanpassen :-)

[Hydra]

Misschien eens een idee om met een profiler te kijken waar 'ie nu zo lang mee bezig is? Een seconde per 1000 objecten ongeveer is bizar lang.

[Woy]

Ik zou inderdaad eens gaan timen wat er zo lang duurt. Dingen als AsParallel zijn leuk, maar het lijk mij dat er een structureel ander probleem is. Word er in de Assignment van een property bijvoorbeeld wat gelogd, of op de een of andere manier IO uitgevoerd? Het creëren van 3000 objecten en wat properties assignen moet gewoon niet zo lang duren!

[ Voor 40% gewijzigd door Woy op 17-08-2010 14:02 ]

[HMS]

Of om even 'evil' yield te gebruiken:

C#:

public static IEnumerable<AndereObjecten> VertaalLijst(IList<BronObjecten> bron) 
{ 
for (int index=0; index<bron.Count; ++index) 
  { 
    yield return new AndereObjecten() 
        { 
          waardeA = bron[index].WaardeC, 
          waardeB = bron[index].WaardeQ 
        }; 
  }
}

Maar dit gaat hoogst waarschijnlijk je probleem toch niet oplossen, omdat het probleem ergens ligt. Zoals Woy al aankaart.

[roy-t]

Probeer eens geen linq syntax te gebruiken maar gewoon een doodnormale forloop. LinQ lijkt altijd heel erg mooi en compact maar onderwater kan er echt heel veel gedaan moeten (worden) voor die regel code. Zo weet ik een voorbeeld waarbij je kon zoeken met linq, waar je verwachte dat dit binarysearch was of zoiets was dit eigenlijk een forloop over de hele collectie.

Edit: yield is niet ev1l, vooral voor parsers is het meesterlijk.

[ Voor 8% gewijzigd door roy-t op 17-08-2010 20:05 ]

[Verwijderd]

is AndereObjecten wel een DTO? zo niet probeer eens een test te maken met dezelfde LINQ code en een dummy POCO class. (Als 'andereobjecten' een domain/business class is lijkt het me beter deze te mappen naar een DTO en deze te serializeren... )

[__fred__]

Draai je code eens zonder debugger met een serieuze stopwatch in je code. Dan zul je zien dat het allemaal wel mee valt. Je debugger hangt nu aan de code, die heeft (veel) tijd nodig om zijn eigen administratie bij te houden. De .NET runtime code wordt niet gedebugged en voert dus een stuk sneller uit.