Lidská hloupost je nekonečná, obzvlášť ta moje.

29.3.2007 18:26 | Přečteno: 1390× | Java | poslední úprava: 29.3.2007 18:32

Po vzoru Leoše Literáka se přiznám ke své v mém případě spíš neznalosti.

Píšu do školy javový program na kreslení animací kinematických křivek. Celé to je postavené na výpočtu jednotlivých bodů a jejich spojování přímkami. Výpočty jsou celkem triviální, kreslení většiny křivek také. Najdou se však křivky, které mají i 15000 bodů. Vykreslení takové křivky trvá docela dlouho (cca 18 ms). Proto jsem se rozhodl optimalizovat.

Optimalizace se zadařila a čas jsem stáhl na třetinu. Přestala však fungovat jiná věc. Při měnění parametrů za běhu se program začal nepříjemně trhat. Dlouhou dobu jsem nemohl zjistit, kde je problém. Celou optimalizaci jsem párkrát předělal, pohrál jsem si se synchronizací a stále nic.

Po nějakém čase mě napadlo porovnat kód se starším, který fungoval v pořádku. Jediný podstatný rozdíl byl ve volání garbage collectoru při každé změně. Přišlo mi to divné, ale zkusit jsem to musel. K mému překvapení se po zakomentování onoho řádky všechno vrátilo do správných kolejí.

Po podrobnějším měření jsem s hrůzou zjistl, že volání System.gc() zažere cca 70 ms. Jindy by to nevadilo, ale když potřebuju překreslovat jednou za 10 ms, tak je to znát.

Je až k nevíře, jak mě objevení téhle prkotiny potěšilo :) ... Chybami se člověk učí :)

       

Obrázky

Komentáře

[vencour]

Kdybych měl pokaždý psát blogspot, když se chytim za nos , ale dobrý ...

[Snilard]

Uznávám je to malichernost. Ale malichernost, která mě dostala natolik, že jsem přehodnotil svůj názor nezakládat si blog :)

[vencour]

Já vim. Jsou věci v životě, co člověka naučí nadhledu a věci, co rozšíří obzory.

[Snilard]

Tak tohle mezi ně patří.
Dřív jsem si myslel, že volání garbage collectoru jen zvýší prioritu jeho vlákna, což by nemělo zabrat moc času. Ale 70 ms na mém docela silném stroji mi vyrazilo dech.

[podlesh]

No jo, RTFM System.gc() by se pokud možno nemělo volat nikdy.

[Luk]

Také jsem si s tím kdysi dávno nabil hubu. V nějakém úkolu do školy jsem vytvářel objekty tak rychle, že to často spadlo na OutOfMemoryError. V první fázi jsem to řešil tou nejhorší možnou cestou - volat explicitně System.gc(). Program se zpomalil naprosto brutálně, takže bylo hned jasné, že tudy cesta nevede

[happy barney]

njn, v učebniciach C++ sa pooling často spomína ... v tých o Jave to asi autori považujú za imperialistický prežitok

[Luk]

V té době tu ještě žádné knihy o Javě nebyly (a pracovalo se v Javě 1.1). Čili by to mohla být chyba přednášejícího, že nás na to neupozornil BTW ani jsem netušil (a zjistil jsem to až teď), že existuje věda stringologie

[Ladicek]

BTW ani jsem netušil (a zjistil jsem to až teď), že existuje věda stringologie

Kdysi jsem kdesi sehnal 220stránkové PDFko celé věnované algoritmům hledání podřetězce v řetězci. Velmi poučné

[Ladicek]

Ale 70 ms na mém docela silném stroji mi vyrazilo dech.

To buďte rád, že ne 10 minut (sic!).

[User682]

No vidite, me se vcera stalo, ze jsem zkratil casy buildu o 1/3-2/5. A to kompiluju Compiera aktivne jiz v mesicich (22MB java kodu a to se hodne modelu generuje). A jedine co me ted pali jsou diskove operace a s nimi dalsi 1GB RAM.

Jenomze to je tim, ze si clovek nesedl k masine a nejak tomu nechtel venovat cas. Specielne ant-u.

Je to nahoda, ze jsem vcera sedel u masiny a chystal se domu a zacal si s danou veci hrat.

Kupodivu kdyz jsem se pred par roky/mesici bavil s Leosem Literakem o ant-u, tak jsem tomuto nastroji nedaval tolik velkou dulezitost.

Co si budeme rikat, tak nejak se mi overuje pravidlo, ze pokud vidite na veci, ze by se asi mela optimalizovat, tak se to da dotahnout do dokonalosti az na 10% casu, ktery to bezelo predtim.

A kdyz zacinate s Javou, tak kazdy si asi projde spojovani retezcu pomoci String += anebo StringBuffer().

No zajimavy pocit, kdyz zjistite, ze neco vlastne neumite, i presto, ze s tim umite pracovat a predtim vsechno fungovalo. I kdyz neefektivne.

bye gf

[Luk]

A kdyz zacinate s Javou, tak kazdy si asi projde spojovani retezcu pomoci String += anebo StringBuffer().

Spojování pomocí String += každý relativně snadno zavrhne, až zjistí, že je to O(n^2). Tedy spíše mu bude divné, že je to najednou nějak strašně pomalé. Ale StringBuffer je z jiného soudku, už proto, že StringBuilder je až záležitost verze 1.5, takže leckdo může StringBuffer používat čistě ze zvyku.

[Snilard]

To, že je sčítání stringů pomocí += neefektivní, je známá věc. Ale jak je to s těma ostatníma, hlavně se StringBuilderem, budu muset nastudovat, nebo otestovat (a nebo mi to někdo osvětlíte?) Vnukli jste mi dobrou myšlenku na studium. Díky
Naštěsí jsem nikdy nepracoval s moc složitými textky, takže mi +=, maximálně StringBuffer.append() stačilo :)

[happy barney]

nemusela by byť neefektívna, keby java dovolila tento operátor si napísať podľa svojho .