Komentář k článku LINQ a lenivé vyhodnocování

Rene — Sun, 21 Feb 2010 09:36:57 GMT

Pěkné kázání o pravdě takhle v neděli. Lazy vyhodnocování mám také rád, ale bohužel je občas matoucí a mnohonásobně dražší než volání metody ToList a ToArray. Představ si, že máš metodu GetUiDescriptors, která na základě volání mnoha dalších služeb a metod business objektů vrátí IEnumerable<IUiDescriptor>. Sada výsledků není ale samozřejmě ani potenciálně nekonečná.:) Když metodu uděláš lazy (yield return), je výhodou pouze to, že neplatíš žádnou režii, jestliže klient nakonec o výsledek volání nemá zájem a kolekci neprojde, což není moc častý případ. Nepříjemná situace nastane, když klient bude výsledek procházet vícekrát. A to nastane už tehdy, když zavolá Count, aby zjistil počet prvků v kolekci a poté kolekci projde. Veškerá režie spojená s voláním služeb a metod business obejktů se platí 2×. Takže vrátit List (klidně skrytý za IEnumerable) je zde mnohem lepší a režie Listu je nepatrná (odstranění Listu ve prospěch Array je podle mých testů zbytečná mikrooptimalizace). IMO by bylo nejlepší, aby u každé metody bylo důsledně zdokumentováno i se symbolem v Intellisense, zda je či není lazy.

Komentář k článku LINQ a lenivé vyhodnocování

Aleš Roubíček — Sun, 21 Feb 2010 11:02:57 GMT

[1] Rene: Jak jsem v článku psal, vždy je potřeba držet se kontextu. Pokud chci vypsat dvacet položek z databáze na stráku, nevyplatí se lazy loading. Pokud ale zpracovávám data, která tečou z nějaké služby, se kterou mi může spojení kdykoli spadnout, pak mi lazy loading přijde ideální.

Ad Count. Pokud píšu aplikaci, kde počítám, že pracuji s proudem dat, nebudu chtít tento proud materializovat. Samozřejmě to musí být zdokumentováno, aby se o to nepokusil někdo jiný. :)

rarouš.weblog - komentáře k článku

Komentář k článku LINQ a lenivé vyhodnocování

Komentář k článku LINQ a lenivé vyhodnocování