Profiler

Ahoj spolužáci,
před několika dny se mi stala nemilá věc, vedoucí RP mi řek, že moje apliace je neskutečné pomalá (já si to taky myslel). Doporučil mi jako řešení software, kterýmu se obecně řiká profiler. Umožňuje, když mu nacpete nějakej zkompilovanej projekt(pravděpodobně jen v Debug modu), vypsat, která funkce se volá kolikrát, jakej má procentuální podíl na procesorovým času celýho projektu atp atd. Neskutečně užitečný. Díky tomuhle infu a odstranění / přepsaní nešikovnejch funkcí sem svoje programy zrychlil někdy i 30x.
Proč to sem píšu? Kdyby to náhodou někdo nevěděl, že něco takovýho je. Z lidí, kterým sem o tom vyprávěl ve škole, znal tenhle pojem jen jeden a to je škoda, na to že sme měli takovejch programovacích předmětů.
Přikládám jeden pro VS2003 - fakt krásnej (ale drahej)
Jinak je jeden taky v instalaci VS, v sekci Tools.
http://www.automatedqa.com/products/aqtime/

RP? Ja jeste nemam ani specifikaci... Ale jestli neco stvorim, tak se prifiler bude hodit...

Jinak tady je zakladni howto jak pouzivat (gnu) profiler:
http://www.logios.cz/~jakub/gnu-profiler.html

http://valgrind.org/
Velmi dobry memory-leak checker, profiler, etc. pre Linux.
Jedna z vyhod je, ze aplikaciu, ktoru chcete profilovat nemusite prekompilovavat. Cital som nejake porovnania a gpref "GNU Profiler" je povazovany za nepresny, ale zase az tak do toho nevidim.
Ak niekto pouzivate KDevelop, je tam priamo frontend "KCacheGrind" pre interpretaciu dat, ktore valgrind vypluje po profilovani.

Nevim kolik lidi pise rocnikovy projekt v .NETu ;-) ale ve Visual Studiu Team Suite takovy profiler pro .NET aplikace je. Dokonce pokud jste byli na Academic Roadshow tak ho Dalibor Kacmar ukazoval.

Nase skola proste nektere pro praxi dulezite veci zanedbava :-)...

tak ja ted optimalizoval jeden algoritmus pomoci gnu profileru a musim rict, ze ma dobre ovladani a celkem rychle sem nasel vec co mi zpomalovala algoritmus ( i kdyz jen trochu..cca 7%).

pro zajimavost tady davam tu optimalizaci

dva vectory a,b;
for (iterator na = a.begin(); na!=a.end(); na++;)
{
//nejaky operace
  for ( const_iterator nb = b.begin(); nb!=b.end();nb++)
  {
    //hodne narocna operace
  }
}

po zkouknuti, ze mi 7% casu probiha volani vector::end(), sem zoptimalizoval takhle

dva vectory a,b;
const_iterator aend = a.end();
const_iterator bend = b.end();
for (const_iterator na = a.begin(); na!=aend; na++;)
{
//nejaky operace
  for ( const_iterator nb = b.begin(); nb!=b.end;nb++)
  {
    //hodne narocna operace
  }
}

coz dost urychlilo beh, protoze hlavne v tom vnorenym cyklu se to volalo mockrat.

No jo, ale tahle uprava se prece neda pouzit vzdycky.
Kdybys mezi tema operacema v cyklech pouzil insert nebo erase,
tak ti to vsechny iteratory zneplatni a program ti odleti.

snail wrote:No jo, ale tahle uprava se prece neda pouzit vzdycky.
Kdybys mezi tema operacema v cyklech pouzil insert nebo erase,
tak ti to vsechny iteratory zneplatni a program ti odleti.

jj, to mas pravdu. Taky kompiler ti nerekne co se spravne a co spatne, jen co zabira kolik casu. Mel sem sem dat i hlavicku, oni ty dva vectory jsou jako vstupni const reference a ten algorimus je jen prochazi a detekuje kolize poligonu.

Ja by som este k tomu dodal, ze sa mi zda, ze bednarek na prednaske tusim vravel, ze pri iteratoroch nemame pouzivat nb++, ale ++nb, pretoze je to rychlejsie.

ps: v tom 2. cykle nema byt bend namiesto b.end? :)

Je to rychlejší, protože se nevytváří temporární proměnná do který by se to kopírovalo, ale jak je to v praxi nevím, třeba se to řeší stejně...