Čas od času se objeví články, které by stálo za to zarámovat a pověsit si nad stůl. Jedním z nich je článek v posledním čísle časopisu THE VIEW, který rozebírá různé možnosti nalézání dokumentů v pohledech a jejich výkonové srovnání. To nejdůležitější, jsem se pokusil sepsat.
Důležitá informace na úvod – neprocházíme celý pohled, ale pouze nalezené dokumenty. Díky tomu jsou výsledky takřka určitě jiné, než kdyby člověk procházel celý pohled.
Jaká metoda nalezení dokumentu je tedy nejrychlejší? Úplně nejrychlejší je kombinace cyklu For (díky tomu, že jsme potřebné dokumenty nalezli pomoci metody GetAllDocumentsByKey, tak víme jejich počet) v kombinaci s metodou GetNextDocument třídy NotesDocumentCollection.
Na druhém místě se umístila kombinace cyklu While s metodou GetNextDocument třídy NotesDocumentCollection. Následuje použití třídy NotesViewNavigator a cyklů While, který je rychlejší, a Do, ten je o kousek pomalejší.
Předchozí výsledky se týkaly kategorizovaných pohledů – jejich procházení je rychlejší než procházení tříděných pohledů, ty jsou na řadě nyní. Zajímavé je, že rychlost je vyšší u kategorizovaných pohledů přibližně o 10% a to již je cítit.
Po procházení tříděných pohledů přichází na řadu metoda FTSearch kombinovaná s cyklem While. U této metody je ale nutné počítat s tím, že aktualizace indexu nemusí být okamžitá a mívá zpoždění. Někdy i citelné, zvláště pokud dochází k aktualizaci pouze jednou denně.
Překvapením asi není, že procházení dokumentů vyhledaných pomocí metody GetDocumentByKey je ještě pomalejší. Po každém posunu na další dokument je totiž nutné otestovat, zda pořád vyhovuje podmínce. I zde platí, že kategorizované pohledy jsou rychlejší.
Využití třídy NotesViewEntryCollection je ještě pomalejší a zde se pravidlo rychlejšího kategorizovaného pohledu obrací – tříděný je rychlejší. Všechny metody jsou ovšem přibližně o 250% pomalejší než vítězové.
Metoda FTSearch třídy NotesView je o 100% pomalejší než stejná metoda třídy NotesDatabase. Ale to ještě není tak špatné – metoda Search třídy NotesDatabase je o dalších 100% pomalejší – což je přibližně 8x pomalejší než nejrychlejší přístup.
Jednoznačným rekordmanem je procházení kolekce pomocí metody GetNthDocument – trvá přibližně 20x déle než nejrychlejší kombinace.
A další zajímavé výsledky?
Načtení hodnoty z dokumentu je nejrychlejší pomocí NotesDocument.ColumnValues, o něco pomalejší je NotesDocument.GetItemValue a nejpomalejší je ten nejobvyklejší zápis – NotesDocument.ItemName. Rozdíly ovšem nejsou velké, největší rozdíl je mezi posledními dvěmi, přibližně 5%.
Záleží také na správně zapsaném názvu pole – pokud se dodrží správná velikost písmen, tak ušetříte přibližně – celé jedno promile.
Pokud si při procházení dokumentů necháte něco vypisovat do stavové lišty, tak počítejte s velkým zpožděním – v testu vyšlo zpoždění přibližně 500%.
Jednu věc jsem před čtením článku netušil – že pozitivní testy jsou výrazně rychlejší než ty negativní. Rozdíl porovnání i = 1 a i <> 1 činí takřka 50%. Využití kouzelného slůvka Not je ještě o kousek pomalejší.
Naproti tomu nastavování vlastnosti AutoUpdate třídy NotesView nemá takřka žádný vliv – ten se počítá v desetinách promile. Musíte tedy hledat jiné důvody, proč tuto vlastnost použít – a ony existují.
Závěr? Vzhůru ke strojům a přepsat skripty. A všichni, kteří máte stejně jako já rádi cykly Do … vězte, že cyklus While je o kousek rychlejší. Všichni, kteří chcete být ještě lepší, vězte, že pomocí C API můžete být ještě rychlejší. Ale to už je zase jiná kapitola.