6 JÄRJESTELMÄSTÄ SAADUT KOKEMUKSET
6.1 Vertailu tavoitteisiin
6.1.4 Järj estelmän suorituskyky
Rakennettujen sovellusten tulee suorituskyvyltään olla tehokkaita, jotta niitä voitaisiin käyttää tavallisissa työasemissa. MUST-sovelluskehittimen tulee pystyä kilpailemaan taulukkolaskentaohjelmistojen, relaatiotietokantojen, perinteisten ohjelmointikielten ja kehittyneiden olio-ohjelmointikielten kanssa.
Keskusmuistin tarve
Mikrotietokoneet ovat kehittyneet nopeasti viime vuosina. Prosessorien suorituskyky ja kiintolevyjen kapasiteetit ovat kaksinkertaistuneet muutaman vuoden välein. Uudet henkilökohtaiset mikrotietokoneet sisältävät usein kattavat multimediaominaisuudet
oheislaitteilleen. Tietokoneiden kehityksessä heikoimmaksi lenkiksi on kuitenkin jäänyt keskusmuisti. Nykyisissä mikrotietokoneissa on usein vain 8 megatavua muistia, joka on minimivaatimus uusien käyttöjärjestelmien (Windows 95) ja perussovellusten (Excel 5.0) käyttöön. Koska MUST-sovelluksen käyttöliittymä on yleensä rakennettu Excel- taulukkolaskimen avulla, joudutaan 8 megatavun muistilla varustetuissa koneissa aina turvautumaan virtuaalimuistiin.
MUST-sovelluksen keskusmuistin tarve määräytyy MOS-kirjaston metaluokkien toteutuksen perusteella. Tarkka selvitys MOS-metaluokkien muistintarpeesta on esitetty liitteessä F. Taulukossa 9 on yhteenveto MUST-järjestelmän peruskomponenttien tilantarpeesta.
Taulukko 9 MUST komponenttien tilantarve
Komponentti Tilantarve tavuina (bytesj
Luokka 200
Instanssi 140
Relaatio 140 + 70 / instanssi
Tietoalkio 120 + 42 / instanssi
Tietoalkion arvo tyypin perusteella
luku:18
lukulista: 26 + 8*alkioiden lkm merkkijono: 24 + 1 * merkkien lkm
Laskentasääntö 426
Otetaan esimerkiksi sovellus, jossa on 10 luokkaa, jokaisessa luokassa keskimäärin 5 luku-ja 10 kahdeksan alkion lukulista -tyyppistä tietoalkiota sekä 4 relaatiota. Mallissa on keskimäärin 20 instanssia jokaisesta luokasta ja kymmenen sääntöä. Mallin muistintarve on taulukon 9 perusteella: 200*luokat + 140* instanssit + 140*perusrelaatiot + 70*periytyneet relaatiot + 120*perustietoalkiot + 42*periytyneet tietoalkiot + 18*lukutyyppiset tietoalkiot + 90*lukulistatyyppiset tietoalkiot + 426* laskentasäännöt, eli 200*10 + 140*10*20 + 140*4 + 70*4*(10*20-1) + 120*15 + 42*15*(10*20-1) + 18*5*(10*20) + 90*10*(10*20) + 426*10 = 415710 tavua. Malli vaatii siis keskusmuistia hieman yli 400 kilotavua.
Vasteajat
MUST-sovelluskehittimen toteutuksessa pyrittiin vasteaikojen kannalta mahdolli
simman tehokkaisiin ratkaisuihin. Suunnittelun lähtökohta oli, että mallin rakenne kokonaisuudessaan mahtuu keskusmuistiin. Metaluokista luotujen instanssien väliset viittaukset toteutettiin suorina osoittimina, luku 5. Erityisesti haluttin kaikkien luvussa 2 mainittujen mallinnus-ja laskentaominaisuuksien olevan käytettävissä interaktiivisesti.
Tähän kappaleeseen on koottu tuloksia kolmesta erityyppisestä vasteaikatestistä. Testit on tehty ICL ErgoPro D5/60 työasemalla, jossa oli suorittimena Intelin 60Mhz Pentium ja keskusmuistia 32 megatavua. Käyttöjärjestelmä oli Windows 3.11 ja muistissa olivat
testien suorituksen aikana ladattuina Microsoft Word 2.0 ja Microsoft Excel 4.0.
MUST-sovellusten käyttöön annettiin keskusmuistia noin 10 megatavua. Kolmannessa testissä käytettiin vertailukoneena Microstar työasemaa, jonka suoritin oli Intelin 486dx33 ja keskusmuistin koko 8 megatavua.
MUST-sovelluskehittimen ja sen avulla rakennettujen sovellusten vasteaikoja tarkasteltaessa on operaatiot mielekästä jakaa kolmeen ryhmään:
• yksittäiset interaktiiviset operaatiot,
• kokonaiseen sovellukseen kohdistuvat operaatiot ja
• virtuaalimuistin avulla suoritetut operaatiot.
Taulukossa 10 on esitetty interaktiivisten perusoperaatioiden vasteaikoja. Kaikkien mallinnusominaisuuksiin liittyvien operaatioiden vasteajat ovat viittä sekunttia lyhyempiä. MUST-sovelluksen kehitysvaiheessa voidaan näinollen kokeilla esimerkiksi erilaisia luokkahierarkioita, instanssiverkkoja tai laskentasääntöjä alkuperäisten tavoitteiden mukaisesti. Perusoperaatiot on viimeistelty erittäin nopeiksi lähinnä siitä syystä, että sovelluksen lataus ja muut suuremmat operaatiot koostuvat useista peräkkäisistä perusoperaatioista.
Taulukkonäkymien päivittymiseen vaikuttaa luonnollisesti näkymässä näytettävien tietojen määrä. Yksittäisen solun päivittyminen kestää vain muutamia sekunnin sadasosia. Mikäli mallissa on pitkiä laskennallisia riippuvuusketjuja, saattaa päivittymistä varten tarvittava laskenta kestää pitempään kuin näkymän ulkoasun päivittäminen. Kokonaisuutena taulukkonäkymien voidaan todeta olevan erittäin interaktiivisia.
Taulukko 10 Yksittäisten interaktiivisten perusoperaatioiden vasteaikoja
Operaatio Kesto
Luokan luominen tai tuhoaminen < 1 s Instanssin luominen tai tuhoaminen < 1 s
Instanssin luokan vaihto < 1 s
Yläluokan lisääminen tai poistaminen < 1 s Tietoalkion luominen tai tuhoaminen < 1 s Relaation luominen tai tuhoaminen < 1 s Mielivaltaisen olion nimen muuttaminen < 1 s
Laskentasäännön jäsentäminen <0,1 s
Attribuutin arvon laskeminen <0,1 s
Attribuutin arvon invalidoituminen < 0,1 s T aulukkonäky män päivittyminen MUSTissa n. 1-2 s Taulukkonäkymän päivittyminen Excelissä n. 1-3 s
Kokonaisen sovelluksen vasteaikojen tarkastelemiseksi valittiin neljä usein toistuvaa operaatiota. Sovelluksen lataamisen vasteaika on tärkeä sekä sovelluksen rakentajan että loppukäyttäjän kannalta. Sovellus on ladattava kokonaisuudessaan muistiin, ennenkuin sen sisältämiä tietoja voidaan tarkastella tai muuttaa. Tallettaminen on tärkeää sovelluksen rakentajan kannalta. MUST ei sisällä Peruuta-toimintoa, jolla viimeinen operaatio voitaisiin peruuttaa, joten sovellus kannattaa tallettaa usein. Uusien instanssien luomiseen kuluva aika vastaa monien yksittäisten mallinnusominaisuuksiin kuuluvien operaatioiden yhteisvaikutusta. Koko mallin uudelleenlaskentaa ei normaalisti tarvitse käyttää. Invalidoitumismekanismi takaa muutosten vaikutuksien huomioimisen yksittäisten attribuuttien tasolla, jolloin eräajotyyppistä laskentaa ei tarvita. Mallin uudelleenlaskentaan kuluva aika kertoo kuitenkin tarkasti tietynkokoisen laskentaoperaation vasteajan. Suuren sovelluksen yksittäinen laskenta voi hyvinkin olla tässä esitettyjen kokonaislaskentojen suuruusluokassa.
Operaatioita testattiin esimerkkimallien avulla. Jokaisen mallin rakenne on sivulla 91 esitetyn mallin kaltainen. Ainoana erona on mallissa olevien instanssien määrä. Kaikki mallit mahtuivat kokonaisuudessaan keskusmuistiin. Testien tulokset on koottu taulukossa 11.
Taulukko 11 Kokonaiseen sovellukseen kohdistuvien operaatioiden vasteaikoja
Operaatio mallissa
Mallin lataaminen 4 s 25 s 61 s
Mallin tallettaminen 2 s 12 s 37 s
Kaikkien johdettujen attribuuttien arvojen invalidoiminen ja laskeminen
2 s 8 s 19 s
200:n uuden instanssin luominen 4 s 6 s 10 s
Mallin lataamiseen, tallettamiseen ja uudelleenlaskentaan kuluvat ajat on esitetty lisäksi graafina kuvassa 27. Lataus- ja talletusajat vastaavat Windows-ympäristön tyypillisiä toimisto-ohjelmistoja instanssien lukumäärän ollessa viidensadan ja tuhannen välillä.
Mikäli ajatellaan yhden instanssin vastaavan taulukkolaskentalomaketta, voidaan aikoja pitää jopa erinomaisina. Tuhannen laskentalomakkeen lataaminen esimerkiksi Excel taulukkolaskimeen kestäisi useita minuutteja. MUST-järjestelmän ongelma on kuitenkin se, että kaikki sovelluksen instanssit on ladattava muistiin ennenkuin sovellusta voidaan käyttää. Oliotietokannan käyttöönotto olisi merkittävä parannus suurille sovelluksille, jotka sen avulla voitaisiin käynnistää lähes vakioajassa.
Lataaminen on selvästi hitaampaa kuin tallettaminen. Tämä johtuu valitusta tiedostoformaatista, kappale 5.1.6. Talletus on hyvin suoraviivainen operaatio ja sen kestoon vaikuttaa lähinnä fyysisen tiedostojärjestelmän nopeus. Latauksen yhteydessä malli on luotava tiedostoon kirjoitettujen ohjeiden mukaisesti, jolloin suuri osa ajasta kuluu MOS-kirjaston rutiinien suoritukseen ja tarvittavan keskusmuistin varaamiseen.
Kuva 27 Sovelluskohtaisten operaatioiden vasteajat
Johdettujen attribuuttien arvojen laskenta voidaan todeta nopeaksi. Testimalleissa jokaisella instanssilla oli kaksi johdettua attribuuttia. Yhden attribuutin arvon laskentaan kuluu yleisesti laskentasäännöstä riippuen noin 0,002 - 0,01 sekunttia. Uuden instanssin luominen kestää instanssin rakenteesta ja mallin koosta riippuen noin 0,02 - 0,1 sekunttia.
Koko sovellukseen kohdistuvat operaatiot joudutaan suorittamaan erikseen jokaiselle sovelluksen instanssille. Kuvassa 28 on esitetty sovelluskohtaisten operaatioiden kestot suhteutettuna sovelluksen kokoon. Yksittäisen operaation kestoa 320:n instanssin mallissa vastaa indeksi 100. Mitä lähempänä suurempien mallien indeksien arvot ovat lukuarvo 100, sitä vähemmän niissä suoritettavat yksittäiset operaatiot ovat hidastuneet.
MUST-järjestelmässä kaikki yksittäiset operaatiot kestävät sitä pidempään, mitä suuremmassa mallissa ne suoritetaan. Esimerkiksi yhden instanssin latausaika 320:n instanssin mallissa on 0,013 sekunttia, 1080 instanssin mallissa 0,023 sekunttia ja 2080 instanssin mallissa 0,029 sekunttia. Tämä operaatioiden hidastuminen johtuu järjestelmän sisältämien listojen kasvusta. Nimien perusteella tapahtuvat hakuoperaatiot on toteutettu binäärihakuna, jolloin niiden aikakompleksisuus on 0(log2N). Suorat viittaukset on talletettu listoihin, joissa haku tehdään yksinkertaisesti selaamalla lista läpi ensimmäisestä alkiosta alkaen. Tällaisen haun aikakompleksisuus on 0(N).
Kuvan 28 mukaan lataus, talletus ja instanssien luonti hidastuvat selvästi enemmän kuin mallin laskenta. Yksi syy on laskenta-algoritmien parempi viimeistely. Toisaalta osa latauksen ja instanssien luonnin yhteydessä muodostettavista tietorakenteista on suunniteltu nimenomaan laskennan tehostamiseksi. Jos rakenteita ei muodostettaisi, hidastuisi laskenta huomattavasti.
Kuva 28 Yksittäisen operaation hidastuminen mallin kasvaessa
Sovelluksen rakennusvaiheessa vasteaikojen voidaan karkeasti todeta koostuvan tasaisesti kaikista kuvassa 28 esitetyistä operaatioista. Indeksien keskiarvoksi 1080 instanssin mallille saadaan 160 ja 2080 instanssin mallille 230. Sovelluksen koon kaksinkertaistuminen aiheuttaa näinollen alle 50 prosentin hidastumisen yksittäisiin operaatioihin. Esimerkiksi lataus- ja talletusajat lähes kolminkertaistuvat sovelluksen koon kaksinkertaistuessa.
MU ST -sovelluskehitin on suunniteltu sen olettamuksen mukaan, että mallin rakenne kokonaisuudessaan mahtuu keskusmuistiin. Metaluokista luotujen instanssien väliset viittaukset on toteutettu suorina osoittimina. Instanssien muistitila varataan C++-kielen
«ew-operaattorilla, joka pyytää käyttöjärjestelmältä tietyn kokoisia muistialueita ja pilkkoo ne tarpeen mukaan pienemmiksi yksiköiksi. Mikäli malli ei kokonaisuudessaan mahdu keskusmuistiin, joudutaan muistisivuja väliaikaisesti siirtämään levylle. Mallin viittausten mukainen eteneminen perustuu siihen, että kaikki muistisivut ovat samaan aikaan muistissa. Mikäli operaation suorittamiseksi tarvittava muistisivujen määrä {working set) ylittää fyysiseen keskusmuistiin mahtuvien sivujen määrän, joudutaan operaation suorituksen aikana samoja sivuja tallettamaan levylle ja lataamaan uudestaan keskusmuistiin.
Taulukossa 12 on esitetty sovellukseen kohdistuvien operaatioiden vasteaikoja 8 megatavun muistilla varustetussa vertailutyöasemassa. Absoluuttisten aikojen jälkeen suluissa olevat luvut ilmoittavat, kuin monta kertaa pitempään operaatiot kestivät verrattuna 32 megatavun muistilla varustettuun työasemaan, katso taulukko 11. Pienessä ja keskisuuressa sovelluksessa operaatioiden vasteajat kasvoivat noin nelinkertaisiksi, mikä johtui lähinnä työasemien erilaisista prosessoreista. Suurimmassa mallissa
eräajona tapahtuvat lataaminen ja tallettaminen pitenivät myös ainoastaan nelin
kertaisiksi. Mallin laskenta sen sijaan kesti seitsemän ja uusien instanssien luonti jopa kolmetoista kertaa pitempään. Ainoa syy näiden operaatioiden ylimääräiseen pitenemiseen oli virtuaalimuistin käyttö. Kaikki operaatioiden tarvitsemat muistisivut eivät enää mahtuneet yhtäaikaa keskusmuistiin, jolloin samoja sivuja jouduttiin siirtämään keskusmuistin ja kiintolevyn välillä.
Taulukko 12 Operaatioiden vasteaikojen kesto vertailutyöasemassa
Operaatio mallissa
320 instanssia
mallissa 1080 instanssia
mallissa 2080 instanssia
Mallin lataaminen 13 s (3) 84 s (3) 256 s (4)
Mallin tallettaminen 8 s (4) 42 s (4) 154 s (4)
Kaikkien johdettujen attribuuttien arvojen invalidoiminen ja laskeminen
7 s (4) 28 s (4) 128 s (7) 200:n uuden instanssin luominen 14 s (4) 26 s (4) 133 s(13)
Taulukon 12 viimeisellä rivillä on esitty 200:n uuden instanssin luomiseen kuluva aika.
Pienimmässä mallissa yhden instanssin luominen kesti noin 0,07 sekunttia, suurimmassa kesto oli jo lähes kymmenkertainen. Mikäli mallin kokoa edelleen kasvatettaisiin, kasvaisivat monien muidenkin yksittäisten operaatioiden vasteajat jopa monikymmenkertaisiksi. Eräiden mallien uudelleenlaskenta on kestänyt useita tunteja liian pienellä keskusmuistilla varustetussa työasemassa. Keskusmuistin loppuminen hidastaa myös kaikki muita työasemassa käytettäviä ohjelmia. Esimerkiksi Excelin ja MUSTin yhteiskäyttöä varten kontrollin ollessa MUSTilla sivutetaan Excel lähes kokonaisuudessaan levylle. Suorituksen siirtyessä Exceliin menetellään päin vastaisesti.
Saatujen kokemusten perusteella on malli jaettava pienempiin osiin viimeistään silloin, kun sen tilantarve ylittää puolitoistakertaisesti keskusmuistin määrän.