[hunspell-fi-devel] libvoikko-0.2 - voikko_do_spell() optimointia
Reijo Tomperi
reijo.tomperi at pp2.inet.fi
Wed Apr 26 12:47:31 EEST 2006
Harri Pitkänen wrote:
>Mutta tuo ehdottamasi optimointi ei taida toimia, koska analyse_item ottaa
>(char *) -tyyppisen parametrin,
>
>
>asia pitäisi ensin korjata Malagassa
>lisäämällä se const tuon funktion prototyyppiin.
>
>
Malagan kotisivut eivät ole viimepäivinä toimineet, joten en saa
yhteyttä ylläpitäjään tuon asian tiimoilta. Tuo on kuitenkin korjaus
joka olisi hyvä Malagaan tehdä vaikka me emme sitä käyttäisikään, koska
se on kuitenkin hyvien ohjelmointitapojen mukaista kertoa const:lla
käytetäänkö parametria vai ei, ja erityisesti merkkijonon tapauksissa
const:n tarpeeton puuttuminen lisää funktion käyttäjän työtä, koska tämä
joutuu tekemään usein tarpeettoman muistivarauksen.
>Toinen asia on sitten se, että tuota voikko_do_spell -funktiota ei kannattane
>muutenkaan optimoida, kun siellä vietetään vain 0,05 prosenttia koko
>oikolukukutsun suoritusajasta.
>
Tiedän tuon, mutta kun se osui silmiin niin eihän siihen voinut olla
puuttumatta.
>Laitoin ihmeteltäväksenne suoritusaikagraafin
>osoitteeseen
>http://www.hunspell-fi.org/voikkotmp/voikkospell-callgrind.png [1]
>
>
Kiitos tuosta. Olinkin pohtinut millä ohjelmalla tuollaisen saisi tehtyä.
>Mutta jos oikein haluaa
>optimoida (mikä olisi kyllä hyödyllistä koska oikoluku saisi toimia
>nopeamminkin) niin kannattaa tutkia Malagaa, erityisesti sen funktiota
>execute_rule. Siellä kuluu 75 prosenttia ajasta, ja tästä silmämääräisesti
>arvioituna vain noin puolet menee edelleen aliohjelmissa.
>
>
execute_rule():a kutsutaan noin 290 kertaa kun tarkistetaan sanaa
"kirahvi". Tämä on sikäli hyvä, että pienikin optimointi ko. funktiossa
pitäisi jo näkyä suoritusnopeudessa. Huono sikäli että paremman tuloksen
saamiseksi pitäisi pystyä vähentämään kutsuja, mikä puolestaan ei ole
välttämättä mahdollista, mutta vaatii vähintään kirjaston toiminnan ja
algoritmien syvällisempää tuntemusta.
Malagan koodi ei myöskään ole kaikkein helppolukuisinta, koska
suurinpiirtein kaikki muuttujien tyypit on tyypitetty toisen nimisiksi
(esim. kun normaalisti käytetään bool tyyppiä, tuolla käytetään
bool_t). Lisäksi mm. execute_rule() tallettaa globaaleihin muuttujiin
muutokset mitä se tekee, mikä ei ainakaan helpota tilannetta.
En kuitenkaan huomannut mitään selkeitä optimoinnin paikkoja
execute_rule():n koodissa. Muutamia sisäkkäisiä for-silmukoita löysin,
mitkä saattaisi pystyä optimoimaan jollain c++:n std::map:n kaltaisella
taulukolla, mutta koska vertailukohteina on ilmeisesti moniulotteisia
taulukoita, missä on sisältönä ties mitä, voi tuokin optimointi mennä
turhan hankalaksi, jos se edes ylipäätään olisi mahdollista.
En nyt viettänyt tuota tutkiessa aikaa kovinkaan montaa tuntia, eli
erehdyksenkin varaa on. Mutta näillä näkymin optimoinnille ei näyttäisi
olevan paljon tilaa. Jos sellaista tarvitaan, voi olla että joudumme
kirjoittamaan Malagasta oman, kevyemmän vastineen, josta poistetaan
kaikki meille turha ja lisätään sääntöjen käsittelyin ohituksia suoraan
koodiin, niiden nopeuttamiseksi. Tuossa olisi kuitenkin oletettavasti
niin iso homma, että siihen tuskin kannattaa ryhtyä ennen kuin meillä on
toimiva versio, eikä muuta tekemistä ole kuin nopeuden optimointia.
More information about the devel
mailing list