@gamer a ostatni. Tak ja se velmi omlouvam, zkoumal jsem, cim to gamer tak urychlil a naprosto zasadni zmena u VS kompileru je nahrazeni istream >> double obycejnym sscanf. Na tom to uplne vyhorelo, a jelikoz nemam profiler, tak jsem to nezmeril. Takze muzeme vzit zpatky vsechny uvahy o kvalite MS stl atd., mozna neni cely tak spatny, ale v parsovani doublu neco shnileho je. Rozdil v mem pripade dela ze 1600ms nejakych 470ms.
Jinak samozrejme, kdyz budu optimalizovat algoritmus, jinak resit zivotnost instanci apod., tak se dostanu na lepsi cisla, ale to uz jsme u toho, nakolik investovat do optimalizaci a nakolik zachovat jednoduchost kodu. Jakmile na tom zacne spolupracovat vic lidi ruznych kvalit/zkusenosti, tak se bude vyplacet drzet kod spis jednoduchy.
A mimochodem, v poslednich letech casto narazim na clanky, ze se programator nema snazit napovidat kompileru tim, ze parametry prijima pres const & (jde o tu referenci) a na tomto prikladu to skutecne nema vliv (spravne mam rict na VS2013 :-) ). I (ne)pouziti u shared_ptr nema meritelny vliv. Na netu toho najdete dost na to tema.
ČLÁNKY DO MAILU