Open dezhidki opened 3 years ago
In GitLab by @vesal on Sep 2, 2021, 10:49
Mika Lehtinen created an issue: #2356
Assignee: Mika Lehtinen
Rupean keräämään tähän korttiin suorituskykymittailuja. Teen varmaan niin, että postaan yhden graafin/mittauksen per kommentti, jotta niihin pystyy paremmin kohdistamaan keskustelua sen sijaan, että olisi kaikki asia itse kortissa.
Onko tähän parempi kortti vai ihan TIM-doku?
In GitLab by @Smibu on Sep 2, 2021, 11:17
Saattaa TIM-dokukin olla ihan ok. Ehkä tähän korttiin voisi sitten keräillä niitä varsinaisia TODO-rukseja, jotka ovat niitä pullonkauloja.
In GitLab by @vesal on Sep 2, 2021, 11:24
Saattaa TIM-dokukin olla ihan ok. Ehkä tähän korttiin voisi sitten keräillä niitä varsinaisia TODO-rukseja, jotka ovat niitä pullonkauloja.
Jos siitä TIM-dokusta saisi sitten sellaisen HowTo ohjeen kun on mittauksia joihin voi viitata.
In GitLab by @Smibu on Sep 3, 2021, 13:40
Lisäsin rukseja profilointien perusteella. Rupean katsomaan noita.
In GitLab by @Smibu on Sep 21, 2021, 15:59
marked the task bleach-kirjasto pois, tilalle lxml:n cleaner, kuten TIMissä on as completed
In GitLab by @Smibu on Sep 21, 2021, 15:59
marked the task mkdirs niin, että kutsutaan vain palvelimen käynnistyessä (luotava hakemistohan on vakio) as completed
In GitLab by @Smibu on Sep 21, 2021, 16:00
marked the task templatelle olioita, ei dictejä as completed
In GitLab by @Smibu on Sep 27, 2021, 16:19
render_plugin_multi
-kutsujen suoritus rinnakkain (requests_futures)
Tuo säästäisi n. 0.2s lokaalilla ohj1-monisteella. Tuotannossa suhteellinen parannus on pienempi, koska get_answers
kestää.
Tämä muutos on haaralla pluginify-futures
, mutta en lähtisi sitä ainakaan vielä mergeämään, koska:
get_answers
: lataa vain osajoukko answerin attribuuteista
Tuo ei vaikuttaisi auttavan yhtään, ja kieltämättä en mitään suurta parannusta edes odottanut.
deepcopy
jen välttäminen
Tuota en ole tutkinut, mutta deepcopyt ovat profiilien mukaan niin pieni osuus kokonaisuudesta, että ei maksane vaivaa tutkia tätä tässä vaiheessa.
Jos Rustin käyttöönottoa miettii, niin helpoimmat kohdat muuntaa Rustiksi olisi varmaankin lohkojen luku levyltä ja YAMLin parsinta. Nämä vaikuttaisivat olevan kokonaisajasta n. 13% (tuotanto ohj1). Eli ihan valtavasti ei pelkästään noista voi säästää.
Iso osa ajasta menee konttien väliseen kommunikointiin, johon Rustin käyttö ei suoraan auta yhtään.
Rust on sinällään "valmis otettavaksi käyttöön" haaralla rust
(ts. tarjoaa tavan kirjoittaa Rustia ja kutsua Pythonissa niitä), mutta näkisin, että noita muita asioita olisi edelleen syytä parantaa ennen Rustia.
Eli koitan mietiskellä vielä lisää ei-rust-optimointeja.
In GitLab by @Smibu on Sep 28, 2021, 16:12
Joitakin optimointi-ideoita tulee vielä mieleen:
call_dumbo
-kutsut voisi jollain lailla cachettaa Redikseen (ainakin timMenun kutsu)get_answers
sin miettiminen
EXPLAIN ANALYZE
)In GitLab by @Smibu on Sep 30, 2021, 21:57
unassigned @Smibu
In GitLab by @Smibu on Sep 2, 2021, 10:24
Ks mittauksia: https://tim.jyu.fi/view/tim/TIMin-kehitys/suorituskyky
csplugin:
tim:
get_answers
: lataa vain osajoukko answerin attribuuteistarender_plugin_multi
-kutsujen suoritus rinnakkain (requests_futures)deepcopy
jen välttäminen