Už sme si povedali, že pre zadaný konkrétny vstup vieme algoritmus odsimulovať a spočítať počet krokov, ktoré spraví. Predstavme si, že toto spravíme pre všetky možné vstupy, ktoré majú veľkosť nanavýš . Následne nájdeme najhorší spomedzi nich, t. j. ten, ktorý donúti náš algoritmus urobiť najviac krokov. Označme tento počet krokov . Túto funkciu budeme volať časová zložitosť algoritmu.
Inými slovami, na spracovanie ľubovoľného vstupu veľkosti najviac určite stačí spraviť krokov.
Vráťme sa k algoritmu z Príkladu 2. Aký je najhorší vstup veľkosti najviac ? Inými slovami, ktoré najviac -prvkové pole si vynúti najviac krokov výpočtu? Ľahko si všimneme, že:
Nuž a zjavne ak budú na začiatku prvky poľa A
v klesajúcom poradí,
štvrtý krok sa zakaždým vykoná. Toto je teda najhorší možný vstup. Náš
algoritmus na ňom spraví krokov.
Teda jeho časová zložitosť je .
Je pomerne očividné, že takto určiť presnú časovú zložitosť pre zložitejší algoritmus by bolo ťažké, ak nie nemožné. Ukazuje sa ale, že to nie je ani nutné. V našom príklade môžeme napríklad zanedbať člen . V porovnaní s je totiž zanedbateľný a takmer neovplyvní čas behu programu. Na to, aby sme vedeli posúdiť rýchlosť nášho programu, nám bohate stačí výsledok: " je približne rovné ". Ako ukážeme o chvíľu, ani na konkrétnej konštante príliš nezáleží.
Predstavme si dva algoritmy: jeden s časovou zložitosťou , druhý . Ľahko vypočítame, že pre väčšie ako je už prvý algoritmus rýchlejší – a s rastúcim sa tento rozdiel rýchlo zväčšuje. Kým prvý algoritmus vyrieši vstup veľkosti za niekoľko sekúnd, druhý už bude potrebovať minúty.
Zjavne podobná situácia nastane vždy, keď jedna z funkcii udávajúcich časovú zložitosť rastie asymptoticky rýchlejšie ako druhá. (T. j. keď pre idúce do nekonečna ide aj podiel týchto dvoch funkcií do nekonečna.) Bez ohľadu na konkrétne konštanty bude algoritmus s časovou zložitosťou lepší od algoritmu s časovou zložitosťou na skoro všetkých možných vstupoch. A na tomto pozorovaní založíme naše formálne definície.