[hunspell-fi-devel] [patch] [suomi-malaga] Lisää yhdyssanakorjauksia
Harri Pitkänen
hatapitk at cc.jyu.fi
Fri May 5 12:58:39 EEST 2006
On Friday 05 May 2006 07:38, Hannu Väisänen wrote:
> Suoritushaarojen karsiminen mahdollisimman aikaisessa vaiheessa on
> paras tapa nopeuttaa ohjelmaa, mutta ...
>
> > Iloinen yllätys oli se, että tämä nopeutti Malagan toimintaa jopa parilla
> > prosentilla.
>
> Ohjelman nopeudella ei ole väliä ellei sillä ihan oikeasti ole väliä.
>
> Jos suomi-malagan nopeus lisääntyy pari prosenttia, kuinka paljon
> lisääntyy koko oikoluvun nopeus?
Suunnilleen yhtä paljon, sillä malagassa vietetään nyt 95 prosenttia koko
prosessin käyttämästä ajasta.
> Mikä on pienin nopeuden lisäys, jonka tekstiään oikolukeva käyttäjä huomaa?
Sainoisin, että jotain 20 prosentin luokkaa. Onko tällä perusteella järkevää
jättää tekemättä kaikki optiomoinnit, joilla ei yksinään ole näin suurta
merkitystä? Tuo aikaisemmin tekemäni optimointi vei pois muistaakseni vain 4
prosenttia suoritusajasta, mutta kokonaisuudessaan result-komentoja
analysoimalla ja turhia haaroja karsimalla voidaan varmasti saavuttaa
merkittäviä parannuksia. Lisäesimerkki (combi_rule teonsana):
result $vasen + <[alku: $sana] + $oikea>,
rules tekijämuodot, nimitavat, laatutavat,
liitesana, liitesana2,
#nimisana, laatusana, teonsana,
teonsanan_johdos,
tavuviiva, loppu;
Tuo kommenttimerkki on minun lisäämäni. Testi ennen muutosta:
$ time cat ../ispell.txt | malaga -m suomi.pro > /dev/null
Analysed wordforms: 61806
Recognised: 59925 (96.96%)
Recognised by combi rules: 59925 (96.96%)
Results per wordform: 1.343
Analysis run time: 41 sec
Avg. wordforms per second: 1507
real 0m41.437s
user 0m41.234s
sys 0m0.114s
Muutoksen jälkeen:
$ time cat ../ispell.txt | malaga -m suomi.pro > /dev/null
Analysed wordforms: 61806
Recognised: 59925 (96.96%)
Recognised by combi rules: 59925 (96.96%)
Results per wordform: 1.343
Analysis run time: 39 sec
Avg. wordforms per second: 1584
real 0m38.864s
user 0m38.661s
sys 0m0.115s
user-aikoja vertaamalla suoritusajasta hävisi 6,2 prosenttia mutta
tunnistettavien sanojen joukko ei muuttunut. Itse asiassa noita sääntöjä
tutkimalla näyttäisi siltä, että ohjelma on loogisesti täysin ekvivalentti
alkuperäisen version kanssa. Nyt olemme saaneet yhteensä jo 10 prosentin
parannuksen, eikä tämä varmaankaan ollut viimeinen paikka jossa tällaista
optimointia voi harrastaa.
Tietysti voi olla järkevää jättää nuo tarkistukset myös kutsuttaviin
jatkosääntöihin. Ohjelma on silti nopeampi vaikka testaus tehtäisiin
molemmissa paikoissa. Omasta mielestäni result-komentojen pilkkominen lisää
myös koodin luettavuutta koska tällöin on selvempää, miksi tiettyä
jatkosääntöä ylipäätään on tarpeen kutsua. Mutta koska olet näitä asioita
paljon pitempään miettinyt kuin minä, niin en väitä vastaan jos kokemus on
sinulle toisin osoittanut :)
Toki voin myöntää, että tämä optimointi ei ole missään määrin pakollista.
Kriittisin paikka on korjausehdotusalgoritmi, koska sen pitäisi suoriutua
yhdestä sanasta alle kymmenesosasekunnissa. Tämä siksi, että
korjausehdotukset tekstinkäsittelyohjelmassa katsotaan yleensä klikkaamalla
oikealla hiiren painikkeella väärin kirjoitetun sanan päältä jolloin valikon
on auettava välittömästi. Ja välittömästi on ihmisen reaktioajoilla suurin
piirtein alle kymmenesosasekunnissa. Toisaalta hyvien ehdotusten tuottaminen
vaatii tekemäni prototyypin perusteella noin 300 sanan tutkimista (pitkillä
sanoilla pitää tutkia enemmän vaihtoehtoja). Siispä Suomi-Malagan pitää
pystyä käsittelemään noin 3000 merkkijonoa sekunnissa. Yllä olevien
esimerkkien mukaan se pääsee tästä vain puoleen (1,2 GHz:n prosessorilla)
mutta onneksi nopeus on suurempi silloin kun merkkijonot eivät ala oikein
kirjoitetulla sanalla. Käytännössä siis näyttäisi siltä, että Suomi-Malaga on
jo tarpeeksi nopea, mutta vain hyvin niukasti. Esimerkiksi Hunspell on noin
10 kertaa nopeampi (tosin ominaisuudet eivät ole ollenkaan
vertailukelpoiset).
More information about the devel
mailing list