Obávám se, že toho moc nevymyslíš.
Za prvé nevím, jak Serializer plní proměnnou. Jestli zavolá kontruktor se
získanými parametry, nebo zavolá kontruktor a poté nastavuje každou poperty
zvlášť. Když smažeš kontruktor, bude to fungovat? Pokud ano, znamenalo by
to, že všechny attributy nastaví null a poté teprve přiřazuje property -
ušetřil bys 6 operátorů přiřazení.
S tím souvisí také samotný cyklus, kde vlastně znovu vytváříš dataInfo.
Co kdybys pouze přepsal původní attributy, které se mění?
foreach (dataInfo di in obj)
{
di.status_v = "Status: " + di.status_v;
string barva;
switch(di.barva)
{
case "ZE": barva = "#FF32FF1D"; break;
case "CE": barva = "#FFFF1D1D"; break;
case "ZL": barva = "#FFF5FF1D"; break;
case "OR": barva = "#FFFFA31D"; break;
case "MO": barva = "#FF1D46FF"; break;
default: barva="x:Null"; break;
}
di.barva = barva;
VypisZakazekli.Add(di);
}Zamezíš zbytečnému vytváření nové proměnné, dalším přiřazovacím operátorům a vytváření nového objektu v paměti.
Poté mě napadá ještě samotný list. Ten se v defaultním nastavením vytvoří jen pro určitý počet prvků, a když přidáš prvek, který se už do listu nevleze, tak se přealokuje (ber to s rezervou, není to realokace v pravém slova smyslu). Příklad: prázdný list může obsahovat 2 prvky. Jakmile se chceš přidat třetí prvek, list se přealokuje, aby mohl obsahovat 4 prvky. Jakmile chceš přidat pátý prvek, opět se přealokuje, aby mohl obsahovat třeba 8 prvků atd. Protože znáš počet prvků, které tam chceš uložit, můžeš toho využít a přímo Listu říct, kolik prvků bude obsahovat (nebude se několikrát volat ona "realokace"). Teď mě nenapadá, jaká je to funkce, zkus se podívat na Capacity property (nevím, jestli není read-only).
Víc mě teď nenapadá.
Díky, zkusím se na to podívat 
- u toho listu já sám nevím kolik tam těch položek bude, protože
na začátku jsou ještě nějaké filtry, takže uživatel si může
vyfiltrovat buď přímo tu jednu zakázku co hledá (ideální případ 
) a nebo si klidně může
zobrazit celou DB (cca 35 000 záznamů... to už aplikace spadne )
jasný, ale v obj už máš vracený počet objektů, které chce zobrazit.
VypisZakazekli.Capacity = obj.Count;Nebo něco tomu podobné.
Ahoj, když tady řešíte tento problém, napadlo mě zkoušel si někdy používat Parallel.ForEach ?
Já bych měl laickou představu, že díky tomu, že to umí pustit paralerně, tak to tu kolekci projede rychleji, ale podle hodinek to trvá naopak násobně krát déle, takže jsem to nikdy vlastně nepoužil nebo se to dá využít na něco jiného ?
Teď jen střílím od boku, ale mám za to, že třída Parallel je určená pro asynchronní metody. V principu nemůžeš tuhle operaci dělat paralelně, protože nevoláš žádnou asynchronní metodu. Abys dostal paralelní zpracováí - musely by se vytvořit vlákna, a to je operace náročná na CPU i na čas.
No ty vlákna právě umí ten Parallel umí obsluhovat sám? Nebo já i když si to zkusím a udělám si nějakou kolekci List a udělám si Parallel.ForEach(List, a akce třeba jenom (x) => { a vypsat thread který to spracová něco jako Thread.CurrentThread.ManagedThreadId }
tak se mi ty čísla Threadů různí, takže to běží na více vláknech. Ovšem celkově pomaleji, než když to udělám klasicky foreach(var x in List){}.....
Píšu to, že se o tom něco chci dozvědět, takže vše co jsem napsal může být od A až do Z kravina, ale takhle jsem to pochopil.
Ono si to asi vytváří vlákna samo, když tomu nepředáš task.
Představ si to takhle - asynchronní metody neblokují vlákno, protože operace probíhá na hardwaru (třeba harddisku). A na tuto operaci musíš počkat (třeba přečtení souboru). Parallel to vyřeší tak, že spustí první úlohu, a když dojde na asynchronní operaci (na kterou by musel čekat), tak mezi tím rozjede ten stejný cyklus ale s dalším objektem v pozadí. A opět, když tento druhý objekt narazí na asynchronní metodu, spustí cyklus pro třetí objekt atd atd. Jakmile je první asynchronní metoda dodělána, zastaví se právě prováděna operace a pokračuje se v prvním cyklu. Tak to funguje pro asynchronní metody.
Pokud nepředáš Task (tedy asynchronní volání), zřejmě si to vytvoří vlákna a rozloží to ty cykly mezi jednotlivé vlákna - jenže vytvoření vlákna je nákladná operace (která může trvat i 100ms - což není málo). Nevím, jak si parallel ty vlákna spravuje, jestli je ničí atd atd, ale je možné, že to bude pomalejší. Když použiješ uvnitř asynchronní metody, tak bude operace rozhodně rychlejší.
problem bude podle me ve view vrstve. uz podle toho co vidim v kodu
case "MO": barva = "#FF1D46FF"; break;
default: barva="x:Null"; break;
podle me tam budou nejake silene konventory a cely kod brzdi jen tento radek
this.ListBox1.ItemsSource = VypisZakazekli;
nehlede na to ze taky zalezi na typ kolekce v pozadi protoze jestli se jedna o
observablecollection ktera urcite zustava neustale prirazena na listbox tak
pri pridani kazdeho itemu muze dochazet k prekresleni.
Zobrazeno 10 zpráv z 10.