Opiskelijataulukko hidastaa sivua #1531

Open dezhidki opened 5 years ago

In GitLab by @Smibu on Sep 17, 2019, 10:55

https://timdevs02-5.it.jyu.fi/teacher/kurssit/tie/ohj1/2019s/eteneminen

Vika koskee isoja timtableja ylipäänsä.

In GitLab by @Smibu on Sep 17, 2019, 11:29

Alustava tutkinta: timtablen stylingForCelliä kutsutaan paljon.

Selvitettävä:

miksi sitä kutsutaan, vaikka ollaan ihan muussa tekstikentässä
onko stylingForCelliä mahdollista optimoida

In GitLab by @Smibu on Sep 18, 2019, 11:38

Loin vastaavanlaisen tilanteen lokaalisti ja sain toistettua hitauden. Tutkin pari asiaa, jotka saattavat auttaa.

In GitLab by @Smibu on Sep 18, 2019, 14:14

@vesal @sijualle

AngularJS:n scopesta kerrotaan:

At the end of $apply, AngularJS performs a $digest cycle on the root scope, which then propagates throughout all child scopes. During the $digest cycle, all $watched expressions or functions are checked for model mutation and if a mutation is detected, the $watch listener is called.

Eli aina kun digest tulee, esim. kun textfieldiin kirjoittaa kirjaimen, niin käydään kaikilta watchereilta kysymässä "oletko muuttunut?". Kun timTablen koko on 350 * 17 kuten tuo demotaulukko, watchereita tulee ainakin 6000 (koska solulla on ng-style), jotka kutsuvat stylingForCelliä ja se alkaa luonnollisesti painaa.

Onkos tuo timtablen solun ng-style tarkoituksella ei-kertabindaus? Jos siihen laittaa kertabindauksen, niin ongelmahan käytännössä korjautuu, koska watchereita ei sitten stylelle tule. Ja vaikuttaisi silti timtablen tyylien editointi toimivan, nähtävästi sen ansiosta, että taulu alustetaan uudelleen.

Laitoin tuon korjauksen devs5:lle. Jos kaikki vaikuttaa olevan ok, niin laitetaan tuotantoon.

In GitLab by @Smibu on Sep 18, 2019, 14:19

Hmm, ikään kuin korjaus auttoi vain Firefoxille. Chromella tökkii edelleen.

In GitLab by @sijualle on Sep 18, 2019, 15:09

nähtävästi sen ansiosta, että taulu alustetaan uudelleen.

Tuon varaan sitä ei kannata jättää, sillä se alustus on vain tableFormissa (ja siitäkin sen voi ottaa attribuutilla pois). Nyt esim https://timdevs02-5.it.jyu.fi/view/users/sijualle/timtabletaskesimerkki ei päivitä tyylejään. Lisäksi tuo oman sarakkeen päivityksen hyöty on aika pieni ja sen voisi optimoida niin ettei taulukko päivitä sitä sarakettaan jos päivityskutsu tuli itseltään.

Tuo uudelleenalustus pitäisi muutenkin erottaa tuosta nykyisestä muuttetujen solujen tarkistuksesta, sillä siinä on tarkistus oliko se muokattu solu valitun käyttäjän rivillä (= eli tarvitseeko dokumentissa näkyviä tekstikenttiä päivittää), vaikka tableForm -> tableForm välisessä päivityksessä sillä valitulla käyttäjällä ei ole mitään väliä. Eli jos muokkaa solua joka ei ole sivupalkista valitun käyttäjän rivillä niin uudelleenalustusta ei tapahdu.

In GitLab by @Smibu on Sep 18, 2019, 15:55

Nyt esim https://timdevs02-5.it.jyu.fi/view/users/sijualle/timtabletaskesimerkki ei päivitä tyylejään.

Joo, niinpä on. Kertabindausta tuohon siis ei voi laittaa.

Lisäksi vaikka ng-stylen ottaa solulta kokonaan pois, niin Chrome tökkii. Profiloinnissa (kun fieldiin kirjoittaa) ei näy mitään erityistä. Digest kestää, mutta itse timtablen metodeissa ei vietetä juurikaan aikaa:

In GitLab by @Smibu on Nov 18, 2019, 09:54

miten saan materiaalia timTableen niin että tuota hitausjuttua voi tutkia

Loin import_accounts-skriptillä 350 Aku Ankkaa, lisäsin ne ryhmään ja laitoin sen ryhmän tableformin parametriksi.

Toinen tapa lienee tehdä vain iso tavallinen timtable, jossa on paljon rivejä ja sarakkeita. Makroilla varmaan saa helposti.

Oma diagnoosini asiasta oli, että Angularin watcheja tulee liikaa eli taulukko pitäisi virtualisoida (= DOMiin laitetaan vain sen verran tavaraa, mitä näkyvillä kerrallaan; näin myös ui-grid tekee). Tai kokeilla Angular 9:ää jahka ehdin ottaa sen käyttöön.

In GitLab by @vesal on Nov 18, 2019, 09:59

Oma diagnoosini asiasta oli, että Angularin watcheja tulee liikaa eli taulukko pitäisi virtualisoida (= DOMiin laitetaan vain sen verran tavaraa, mitä näkyvillä kerrallaan; näin myös ui-grid tekee). Tai kokeilla Angular 9:ää jahka ehdin ottaa sen käyttöön.

Onko ihan varma että tuossa kannattaa käyttää mitään työkalua? Jos itse taulukon sisältö olisi puhdasta html:ää, niin voiko mikään olla nopeampaa? Eikö reactikin joudu lopulta työntämään sen virtuaalidomin oikeaan domiin?

Jos siinä kohti missä TIMissä luodaan datamatrix (vai mikä sen nimi oli), loisi itse sen vastaavan DOM-puun tablen osalta ja pitäisi omissa osoittimissa viitteet noihin td elementteihin, niin niitä ei tarviis koskaan etsiä ja itse tiedetään mikä milloinkin päivittyy, niin ei tarvita mitään päivityskierrosta.

Vesa

In GitLab by @Smibu on Nov 18, 2019, 10:06

Jos siinä kohti missä TIMissä luodaan datamatrix (vai mikä sen nimi oli), loisi itse sen vastaavan DOM-puun tablen osalta ja pitäisi omissa osoittimissa viitteet noihin td elementteihin, niin niitä ei tarviis koskaan etsiä ja itse tiedetään mikä milloinkin päivittyy, niin ei tarvita mitään päivityskierrosta.

Tuo on toki toinen tapa ja sen hyöty virtualisointiin verrattuna on, että Ctrl+F toimii.

Aloitan nyt tätä tutkimaan tarkemmin. Pistän viestä tänne eikä timvkhon, jotta tämä ei katoa:

Testasin nyt kaikki mahdolliset taulukkotyypit, jolla saisi tämän hidastuksen mahdollisesti pois, ja tein siitä koosteen:

https://deni.sh/angular_tabletest/

Ja vastaava lähdekoodi: https://github.com/dezhidki/angular_tabletest

(huom., että testauksen tarkoituksena oli pikemminkin latausnopeus -- esim virtuaalisen skrollauksen taulu on vielä ihan alkeellinen eikä täysin optimoitu skrollauksen kanssa)

Tämän perusteella lähden tuota nyt kehittämään niin, että taulun alkiot luodaan DOM API:n avulla suoraan, ja siihen liitetään asetus, jolla taulu voi muttaa lennosta virtuaaliseksi. Eli vähän, mitä Vesakin ajatteli timvk:n viesteissä. Siispä se olisi yhdistelmää testisivulla olevaa "DOM taulua" ja "DOM + virtuaalinen skrollaus".

Nyt kun muutenkin otetiin IE-tuki pois, suoran DOM API:n käyttö onnistuu ihan hyvin ilman jQuerya.

In GitLab by @vesal on Jul 2, 2020, 20:12

Hieno!

Toku tuo DOM + Virtuaalinen skrollaus on nopea, mutta munkin koneella skrollaus tuntuu hieman tahmealta. Entä sellainen "ikkuna", jossa on enemmän DOM-puussa kuin mitä näkyvässä ikkunassa tarvitaan. Jolloin rullaus voisi tapahtua (???) HTML ehdoilla, mutta siellä näkyvän ulkopuolella lasketaan valmiiksi lisää "tavaraa" DOM-puuhun. Välttämättä ei tarvitse laskea edes joka eivin jälkeen vaan kun tullaan riittävän likelle sitä, että uusi tulisi kohta näkyviin.

Vähän kuten JyPelin rullaava tausta että siellä on 3:n ruudun verran tavaraa valmiina.

Saisiko muuten samalla katsottua miten saa kiinteitä sarkkeita ja rivejä (jotka voi konffata montako riviä/saraketta ei rullaa).

Toku tuo DOM + Virtuaalinen skrollaus on nopea, mutta munkin koneella skrollaus tuntuu hieman tahmealta.

Joo, se on tällä hetkellä vähän hitaampi, osittain siitä, että toteutus on mallia "proof of concept".

Entä sellainen "ikkuna", jossa on enemmän DOM-puussa kuin mitä näkyvässä ikkunassa tarvitaan. Jolloin rullaus voisi tapahtua (???) HTML ehdoilla, mutta siellä näkyvän ulkopuolella lasketaan valmiiksi lisää "tavaraa" DOM-puuhun.

Joo, näin periaatteessa tuo virtuaalnen skrollaus toimii (sillä erolla, että nyt niitä DOM-päivityksiä tulee skrollauksen aikana melko paljon). Siinä on nytkin sellainen juttu, että se laskee muutaman alkion näkyvän taulun ulkopuolelta, mutta se tällä hetkellä laskee vain 1-2 alkiota ylös ja alas. Jos sen saa vaikka kasvatettua niin, että se laskisi niitä reilusti enemmän, jotta DOM-päivityksiä ei tulisi vasta silloin, kun on skrollatu pidempään matkaan alas.

Tai tarkoitatko juuri niin, että niitä DOM-rivejä lisätään aina silloin, kun on skrollattu pidempään? Nyt virtuaalinen skrollaus toimii niin, että se muokkaa jo DOMissa olevia rivejä vastaamaan näkyvää sisältöä eikä lisää yhtään uutta. Tuo uusien lisääminen on ihan kokeilemisen arvoista, koska sillä saisi varmaan tuota skrollauksen käsittelijän erittäin pieneksi (tai jopa kokonaan pois).

Saisiko muuten samalla katsottua miten saa kiinteitä sarkkeita ja rivejä (jotka voi konffata montako riviä/saraketta ei rullaa)

Joo, katson ne samalla, koska tuo asetus tarvitaan virtuaalisessa skrollauksessa. Ne pitäisi saada ihan CSSllä.

Lähden seuraavaksi jatkokehittämään taulukko-komponenttia enemmän toimintakuntoon. Samalla testaan tuota ikkuna-ajatusta sekä yleisesti sitä, miten virtuaalista skrollausta saataisiin nopeaksi. Myös samaan aikaan mietin tälle sopivan rajapinnan, jotta se ei olisi liian kökkö käyttää Angularin kanssa.

In GitLab by @vesal on Jul 3, 2020, 01:11

Teitkö jotakin v+dom koska se nyt tunnu niin nahkealta?

En ole tänään päivittänyt tuota julkista testisivua vielä. Mutta on se ihan oletettua tuosta "proof of concept" toteutuksesta. Lähden seuraavaksi tekemään siitä puhtaan version.

In GitLab by @vesal on Jul 3, 2020, 01:47

Jännää että ipafillä jopa Angular-taulu valmistuu n 4 sek.

In GitLab by @vesal on Jul 3, 2020, 11:50

Jännää että ipadillä jopa Angular-taulu valmistuu n 4 sek.

Ja mun suht tehokkaa pöytäkoneella 14 sek...

Sain nyt vietyä sen pidemmälle yhdistämällä tavallinen DOM taulukko ja virtuaalinen taulukko yhteen komponenttiin (eli siis voi vaihtaa, kumpaako muotoa käyttää). Vielä on tekemistä, mutta ainakin olennaisimmat toiminnot liittyen skrollaukseen ja näytön koon mukautukseen ovat paikalla.

Tässä testiversio: https://deni.sh/angular_tabletest/ (teen edelleen omassa repossa kunnes se on siinä muodossa, että voi portata TIMiin). Koodi on myös omassa repossa toistaiseksi.

Testien jälkeen päädyin tuohon Vesan ikkuna-ajatukseen, mikä Chromella auttoi hieman skrollauksen kanssa. Vielä on omalla koneella pientä tahmeutta, mutta se johtuu hyvin todennäköisesti siitä, että

En vielä optimoinnut kaikki laskut täysin
Tällä ikkuna ei ole valtavan suuri testissä: tällä hetkellä DOMiin laitetaan 1 (näkyvä) + 1 (ylös) + 1 (alas) ikkunan verran rivejä, ja rivit päivitetään, kun käyttäjä skrollaa viimeisen näkyvän ikkunan kohdalle.
Chromessa on joku jännä juttu, että se ei skrollaa DOMia ihan 100% oikeaan kohtaan, minkä takia se ikkunan päivityksen aikana hyppää hieman ja näin lisää tahmeuden efektiä). Firefoxissa ja Chromen mobiiliversiossa tuota vikaa ei ole. Koitan vielä tätä katsoa tarkemmin ja korjata.

Pyrin tämän kuun aikana saada koko homman MR:ksi. Tämä ei ole sinänsä suuri muutos, mutta vaatii aika paljon testausta kehittämisen aikana.

P.S. Huomasin muuten tuon saman, että Safarilla ja Firefoxilla Angular-taulukkokin käyttäytyy vähän inhimillisemmin (ja virtuaalinen skrollauskin toimii paremmin ilman hienosäätöjä). Joku Chrome-juttu tässä on.

EDIT: Korjattu ikkunan koko viestissä
EDIT2: Tajusin, että voin skrollauksen yhteydessä näkyvän ikkunan päivittämisessä pyytämään selaimelta tekemään se useamman piirtokerran aikana, mikä vähentää tökkimistä merkittävästi.

In GitLab by @vesal on Jul 8, 2020, 16:19

Vaikuttaa hyvältä. Muista myös kiinteät alkusarakkeet.

In GitLab by @vesal on Jul 9, 2020, 07:30

Jännää. Yksinään iPadillä toimii hyvin, mutta kun aukaisen vanhan Angular-taulun, niin sitten tuon uuden sivuscrollauksessa inputit hyppelevät.

Joo, tuo näköjään Chromella hidastaa sivua entisestään, kun on kummatkin päällä.

Näyttää siltä, että Angular jostain syystä ajaa hirveän määrän muutoksentarkistuksia skrollauksen yhteydessä. Otin ne pois, ja ongelma korjaantui.

Teenkin sitten niin, että otan muutoksien havannoinnin pois uuden taulukon skrollauseventistä, koska siellä ei komponenttia päivitetä. Ainoastaan muutetaan DOM-elementtien ominaisuuksia tarpeen mukaan. En kyllä tiedä, tuleeko tuota ikinä vastaan TIMissa, mutta ihan varulta sen korjaaminen ei haittaa.

In GitLab by @vesal on Jul 9, 2020, 10:01

Toimiikos ikkunointi myös sivuttain jos on leveä taulukko?

Vai lähdetäänkö siitä että korkeussuunta on aina se ongelma?

En tehnyt ikkunointia sivuttaissuuntaan -- ainakaan vielä.

Ajattelisin, korkeussuunta on ehkä se suurin haaste. Ellei sitten ole tilanteita, jossa on >100 saraketta.

En kyllä tiedä, voihan minä lisätä sen saman ikkunoinnin myös sivuttaissuuntaan.

In GitLab by @vesal on Jul 9, 2020, 10:29

ne kummankon suunnan ikkunakoot voisi olla attribuuttina.

In GitLab by @vesal on Jul 18, 2020, 12:05

Voisi miettiä miten luvuille saa muotoilua (desimaalimäärä ainakin)

In GitLab by @vesal on Jul 18, 2020, 12:22

Aktiivisen rivin (ja sarekkeen) markitseminen

TIM-JYU / TIM

Opiskelijataulukko hidastaa sivua #1531