optimalizace aplikace pro WM5
Mam aplikaci, ktera spousti algoritmus, ktery na zaklade nekolika vstupnich argumentu a cca 10kB textoveho souboru v resource vypocte urcity retezec (je to v podstate prepis PassKool z Pythonu do C#).
Na PPC2003 zarizeni se aplikace chova bez problemu - algoritmus probehne behem cca vteriny. Pokud spustim aplikaci z VS2k3 na PDA s WM5, tak aplikace bezi v podstate podobne rychle jako na PPC2003. Pokud ale PDA od VS odpojim a spustim aplikaci primo, tak vypocet trva cca 5x delsi dobu (5-6 vterin). Zkousel jsem i menit cpu power mode, ale vysledek porad stejny.
Logovanim jsem zjistil, ze ve vsech pripadech stravi vypocet nejdelsi dobu (cca 80% celeho vypoctu) jednim cyklem, kde se pracuje pouze s naplnenymi ArrayListy a Hashtable - zadne nacitani resource/souboru apod.
Nevi nekdo, proc se takhle WM5 zarizeni chova? skoro to vypada, jakoby to byl problem s pomalou flash pameti misto spousteni aplikace z rychlejsi RAM, ale pokud vim, tak WM5 by mely aplikaci pred spustenim do RAM snad zkopirovat... taky mi neni jasne, proc se aplikace chova jinak pri spusteni z VS a spusteni primo na PDA - umi to nekdo vysvetlit?
existuje treba nejaka moznost, jak zkompilovat MSIL do nativni aplikace, abych mohl aplikaci urychlit? nebo nejaky jiny napad, jak dosahnout podobne rychlosti jako na PPC2003? tech cca 5s je pro nasazeni algoritmu na WM5 v praxi nerealne :((
Na PPC2003 zarizeni se aplikace chova bez problemu - algoritmus probehne behem cca vteriny. Pokud spustim aplikaci z VS2k3 na PDA s WM5, tak aplikace bezi v podstate podobne rychle jako na PPC2003. Pokud ale PDA od VS odpojim a spustim aplikaci primo, tak vypocet trva cca 5x delsi dobu (5-6 vterin). Zkousel jsem i menit cpu power mode, ale vysledek porad stejny.
Logovanim jsem zjistil, ze ve vsech pripadech stravi vypocet nejdelsi dobu (cca 80% celeho vypoctu) jednim cyklem, kde se pracuje pouze s naplnenymi ArrayListy a Hashtable - zadne nacitani resource/souboru apod.
Nevi nekdo, proc se takhle WM5 zarizeni chova? skoro to vypada, jakoby to byl problem s pomalou flash pameti misto spousteni aplikace z rychlejsi RAM, ale pokud vim, tak WM5 by mely aplikaci pred spustenim do RAM snad zkopirovat... taky mi neni jasne, proc se aplikace chova jinak pri spusteni z VS a spusteni primo na PDA - umi to nekdo vysvetlit?
existuje treba nejaka moznost, jak zkompilovat MSIL do nativni aplikace, abych mohl aplikaci urychlit? nebo nejaky jiny napad, jak dosahnout podobne rychlosti jako na PPC2003? tech cca 5s je pro nasazeni algoritmu na WM5 v praxi nerealne :((
Co to prevest cele na VS2K5 a .NET CF 2.0? Subjektivne mi ten kompilator MSIL v .NET CF 2.0 prijde rychlejsi a i ty apps se chovaji rychleji, nez v .NET CF 1.0...
Faktoru, proc je to na WM5 pomalejsi je mnoho... ROMka, malo dostupne RAMky (vice pagovani, nekopiruje se cely program, ale pouze cast), taky neco trva kompilace (navic v WM2K3(SE) je .NET CF instalovany do RAM)... Ja osobne bych to videl na pomalost Flash pameti...
Kompilace MSIL do nativu v .NET CF nejde...
Faktoru, proc je to na WM5 pomalejsi je mnoho... ROMka, malo dostupne RAMky (vice pagovani, nekopiruje se cely program, ale pouze cast), taky neco trva kompilace (navic v WM2K3(SE) je .NET CF instalovany do RAM)... Ja osobne bych to videl na pomalost Flash pameti...
Kompilace MSIL do nativu v .NET CF nejde...
diky za reakci a vysvetleni. s VS2k5+CF2 to vyzkousim, jakmile mi dorazi instalacky - zatim ho bohuzel nemam.
nicmene porad i pres Vase vysvetleni mi unika jedna vec - proc se to pri spusteni z VS chova jinak nez pri spusteni primo? jakoby v pripade spusteni z VS bud jinak zacal fungovat CF na PDA nebo cast vypoctu obstaralo PC (imho nesmysl)...
nicmene porad i pres Vase vysvetleni mi unika jedna vec - proc se to pri spusteni z VS chova jinak nez pri spusteni primo? jakoby v pripade spusteni z VS bud jinak zacal fungovat CF na PDA nebo cast vypoctu obstaralo PC (imho nesmysl)...
Jinak ten C# 2.0 by měl ještě další podstatnou výhodu, namísto obecného ArrayListu můžete použít generiku (šablonu) s typovou kontrolou na váš konkrétní objekt, to práci se seznamem taky významně zrychlí (pokud se tedy nejedná o primitivní typy, kde stejně nejvíc času zabere boxing a unboxing)
Tipnul bych si, ze ve sve aplikaci vytvarite/rusite velke mnozstvi objektu - pak bude mit na rychlost Vasi aplikace vliv Garbage Collector.
Pokud chcete vedet, co se ve Vasi aplikaci deje, tak pro svou aplikaci pouzijte tento postup
Při vývoji aplikace pod compact .Net Frameworkem nám chybí základní statistiky o běhu aplikace, respektive o výkonnosti běhového prostředí. Alespoň základní výkonnostní ukazatele (Performance Counters) zjistíme po přidání klíče HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework\PerfMonitor do registrů. Pod nově vytvořený klíčem přidáme novou položku typu DWORD, nazveme ji Counters a její hodnotou bude číslo 1.
Pak můžete spustit jednu CF aplikaci, simulovat běžnou práci uživatele a po ukončení aplikace analyzovat nově vygenerovaný soubor mscoree.stat v kořenovém adresáři PDA.
Vice jsem psal zde
Pokud chcete vedet, co se ve Vasi aplikaci deje, tak pro svou aplikaci pouzijte tento postup
Při vývoji aplikace pod compact .Net Frameworkem nám chybí základní statistiky o běhu aplikace, respektive o výkonnosti běhového prostředí. Alespoň základní výkonnostní ukazatele (Performance Counters) zjistíme po přidání klíče HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework\PerfMonitor do registrů. Pod nově vytvořený klíčem přidáme novou položku typu DWORD, nazveme ji Counters a její hodnotou bude číslo 1.
Pak můžete spustit jednu CF aplikaci, simulovat běžnou práci uživatele a po ukončení aplikace analyzovat nově vygenerovaný soubor mscoree.stat v kořenovém adresáři PDA.
Vice jsem psal zde
