Grid met 35k cellen en performance issues

[siepeltjuh]

Bij het verdelen van medewerker uren over activiteiten/projecten is het krijgen van overzicht best lastig. Ik gebruik daar enige tijd een Excel document voor, op zich werkt dit prima, echter loop ik ook geregeld tegen bepaalde problemen aan. De ins en outs zal ik nu even laten voor wat het is, want dat is voor deze post niet zo belangrijk. Om deze problemen het hoofd te bieden ben ik dit weekend aan de slag gegaan om een variant te maken in een .NET webapplicatie. Niet alleen leerzaam, ook nog eens praktisch :-)

De gekozen oplossingsrichting is een tabel met verticaal de activiteiten en horizontaal de medewerkers. Door gemiddeld een 150-200 medewerkers en 150-200 activiteiten komt de tabel grofweg op 35000 cellen. Het op het scherm slingeren van deze cellen is dan ook het hoofdprobleem:

1. De pagina wordt al snel 500kbyte groot
2. Het initieel renderen van 35k cellen
3. Het scrollen gaat met hoten en stoten

Zoals gezegd dit weekend heb ik besteed aan een eerste versie. Deze is nog niet interactief en voorzien van uitgebreide opmaak. Linkje: http://leosiepel.nl/t/test.html


Naast algemene tips voor cosmetische en technische verbeteringen heb ik concreet twee vragen:

• Voor het scrollen maak ik nu gebruik van een tabel die achter een div valt en met jQuery en scrollLeft / scrollTop heen en weer geschoven wordt, dit hakt, is er een beter mechanisme?
• Met enkele optimalisaties is het me gelukt om het HTML-bestand van 4MB naar 450KB te verkleinen, zien jullie nog verbeteringsmogelijkheden?

[Klaasvaak]

Dat hakken lijkt te komen door de gekantelde header cellen. Als ik de css transforms uitzet gaat bij mij het horizontaal scrollen soepel. Het HTML-bestand kan een stuk kleiner door alle lege cellen van <td>&nbsp</td> te veranderen naar <td></td>.

[Wolfboy]

siepeltjuh schreef op zondag 08 maart 2015 @ 21:38:
Voor het scrollen maak ik nu gebruik van een tabel die achter een div valt en met jQuery en scrollLeft / scrollTop heen en weer geschoven wordt, dit hakt, is er een beter mechanisme?

Voor iets betere performance kan je het natuurlijk ook direct met javascript doen in plaats van jQuery, maar waarschijnlijk boek je daar niet heel veel winst mee.

Alles in 1 grote tabel stoppen is waarschijnlijk sneller dan, al zitten dan je scrollbalken natuurlijk wel rechts en onder en heb je geen vaste headers meer.

Met enkele optimalisaties is het me gelukt om het HTML-bestand van 4MB naar 450KB te verkleinen, zien jullie nog verbeteringsmogelijkheden?

Minder/geen inline css classes zou helpen, in plaats van "class=skew" bij elke td kan je natuurlijk ook gewoon een "class=skew" op de tr zetten.

Sowieso begrijp ik niet waarom bijna elke td daarin nog een span heeft. Dat zou prima gewoon met alleen een td kunnen lijkt me.

Bij mij draait het overigens best soepel dus het is sowieso nog afhankelijk van je computer/browser. Een andere optie om je rendering snelheid flink te verhogen is door de elementen serverside te renderen, een png met alleen zwart/witte tekst kost ook bijna geen ruimte en is veel sneller te renderen.

[ Voor 12% gewijzigd door Wolfboy op 09-03-2015 02:26 ]

[RobIII]

Even over een andere boeg: zo'n big-ass tabel is toch gewoon praktisch alleen al onbruikbaar? Laat staan dat 't technisch misschien niet helemaal lekker werkt. Ik neem aan dat je 150-200 medewerkers niet allemaal in dezelfde "groep" zitten en idem voor je 150-200 projecten? Waarom probeer je het geheel niet een beetje behapbaar te maken door een tabel per projectgroep en medewerkergroep te maken? Dan maak je eerst een selectie van de groep(en) waarin je zit* en krijg je je uren te zien in een tabel die overzichtelijk(er) is en in 1 keer op 't scherm past en idem voor degene die de uren gaat toewijzen.

* En die selectie hoef ik niet eens handmatig te maken; het systeem weet natuurlijk in welke groep(en) ik zit a.d.h.v. mijn login.

[ Voor 9% gewijzigd door RobIII op 09-03-2015 08:48 ]

[Douweegbertje]

RobIII schreef op maandag 09 maart 2015 @ 08:47:
Even over een andere boeg: zo'n big-ass tabel is toch gewoon praktisch alleen al onbruikbaar? Laat staan dat 't technisch misschien niet helemaal lekker werkt. Ik neem aan dat je 150-200 medewerkers niet allemaal in dezelfde "groep" zitten en idem voor je 150-200 projecten? Waarom probeer je het geheel niet een beetje behapbaar te maken door een tabel per projectgroep en medewerkergroep te maken? Dan maak je eerst een selectie van de groep(en) waarin je zit* en krijg je je uren te zien in een tabel die overzichtelijk(er) is en in 1 keer op 't scherm past en idem voor degene die de uren gaat toewijzen.

* En die selectie hoef ik niet eens handmatig te maken; het systeem weet natuurlijk in welke groep(en) ik zit a.d.h.v. mijn login.

^

Heel erg eens met hierboven.

De gekozen oplossingsrichting is een tabel met verticaal de activiteiten en horizontaal de medewerkers.

Slecht gekozen
Nee even serieus, waarom ben je op die conclusie gekomen? Ik persoon zie geen enkel voordeel voor zo'n opzet. Iemand wilt zien wat hij wilt zien, hem zowel op de X als Y as te laten scrollen als een jecko schiet dan niet erg op..

Ik heb ooit iets moeten maken waar ook enorm veel data uit het systeem werd gegooid. Hier heb ik uiteindelijk pagination op gezet, maar dan heb je alsnog 10000 pagina's. Vervolgens er search mogelijkheden op gezet op elke kolom zodat je kan filteren op je eigen specifieke data. Result; enkele pagina's, afhankelijk hoe ver je filtert.
Vervolgens sorteer mogelijkheid toegevoegd, en zodoende kun je met een paar klikken -wel- relevante data ophalen -zonder- zware queries of wat dan ook.

Vervolgens kun je dat ook nog met wat ajax of w/e oplossen zodat de belasting wat minder wordt (of meer, maar dan wat meer gebruikersgemak.. afhankelijk van de implementatie ).


---

edit;

oh en ja je voorbeeld werkt wel prima in mijn browser. Als ik dat op onze terminal servers ga draaien krijg ik waarschijnlijk ook problemen. Die zijn er meestal niet op berekend dat een browser even 500mb geheugen gaat pakken (als je veel data zou hebben).

[ Voor 6% gewijzigd door Douweegbertje op 09-03-2015 18:27 ]

[R4gnax]

Technisch gezien is dit perfect haalbaar via een virtual scrolling oplossing, maar ik schaar me toch ook bij mijn voorgangers. Dit is gewoon niet praktisch en de UX van dit type interface is verschrikkelijk.

[Caelorum]

Grappig dat jullie opmerken dat het niet praktisch is en de ux kut is, terwijl ik toch iets heel anders lees in zijn comment. Hij is namelijk zelf de gebruiker van de software en vind het dus wel handig:

siepeltjuh schreef op zondag 08 maart 2015 @ 21:38:
Bij het verdelen van medewerker uren over activiteiten/projecten is het krijgen van overzicht best lastig. Ik gebruik daar enige tijd een Excel document voor, op zich werkt dit prima, echter loop ik ook geregeld tegen bepaalde problemen aan. [...]

Persoonlijk kan ik mij daar ook wel iets bij voorstellen als hij echt alle medewerkers moet verdelen over alle projecten op zodanige manier dat alles 'ok' is. Dan is zo'n overzicht waarbij je snel kan schuiven best handig. Een en ander hangt natuurlijk wel af van de hints die de interface geeft als een medewerker over capaciteit is.

@siepeltjuh het rendert hier ook best snel. Initieel laden duurt inderdaad wat langer, maar daar ontkom je eigenlijk niet aan als al deze data daadwerkelijk nodig is om het overzicht te krijgen. Ik ben het wel eens met RobIII (en de anderen) dat als* je *niet* alle informatie nodig hebt dit niet de way to go is.

[André]

Even los van het feit of het bruikbaar is: ik denk dat de grootste performance problemen zitten in de tabel. Bij elke rij die er bij komt waar een cel in zit die breder is dan andere cellen in dezelfde kolom moet de hele tabel opnieuw uitgerekend worden. Dit voorkom je door de tabel met table-layout:fixed te fixeren. Wel moet je dan handmatig de kolommen een breedte geven.
Daarnaast zorgt het scrollen met de scrollleft en scrolltop er voor dat er reflows ontstaan, dus de pagina wordt dan continu opnieuw doorgerekend, en dan gaat het scrollen haperen.

[ Voor 4% gewijzigd door André op 09-03-2015 21:54 ]

[Damic]

Hier rendert het ook soepel als ik dnetc gpu afzet dit op Waterfox en een r9 280x

Trouwens ik zou de cellen waar iets in staat een andere kleur geven als achtergrond

[R4gnax]

[b][message=43872999,noline]
Persoonlijk kan ik mij daar ook wel iets bij voorstellen als hij echt alle medewerkers moet verdelen over alle projecten op zodanige manier dat alles 'ok' is. Dan is zo'n overzicht waarbij je snel kan schuiven best handig. Een en ander hangt natuurlijk wel af van de hints die de interface geeft als een medewerker over capaciteit is.

Dan nog is het bij die hoeveelheden in een tabulaire weergave een kwestie van door de bomen het bos niet meer zien.

In dit geval moet je veel sneller gaan denken aan een data-visualisatie die medewerkers rondom projecten clustert en omgekeerd; projecten rondom medewerkers. Visueel herken je dan veel sneller welk project of welke medewerker er overboekt is en in hoeverre.

Maak e.e.a. versleepbaar om urenbestedingen op grove schaal al aan te passen en hanteer vervolgens nog een apart gefiltered tabulair invoerscherm voor detailinvullingen.

[siepeltjuh]

Oke, zojuist heb ik op basis van bovenstaande feedback een nieuwe versie gebrouwen: http://leosiepel.nl/t/test_v2.html

@Klaasvaak
De gekantelde header maakt het overzicht prettiger in gebruik en geef ik in deze fase liever nog niet op. Als er een methodiek is die vergelijkbare functionaliteit biedt met betere performance zou ik dat ook nog wel willen onderzoeken.

@Wolfboy
Scrollbalken op een andere plek maakt me niet uit. Dat de headers niet meer vast staan, dat is te belangrijk om te schrappen. Uiteraard ben ik ook benieuwd naar andere technieken om koppen vast te zetten, echter kan ik weinig bruikbare trucs vinden.
De html is verder geschoond: van 470 naar 299 KB:-) De laatste spans staan er nog in samen met onderstaande CSS omdat anders de tabelcellen niet meer een 'vaste' en gelijke breedte hebben. Ik had al gelezen dat width van een tabel anders werkt dan de width van een span, maar moet me nog verdiepen in de exacte werking daarvan.

Cascading Stylesheet:

table.ActiviteitGridView td, table.UrenVerdelingGridView td{
    width: 37px;
}

table.ActiviteitGridView td span, table.UrenVerdelingGridView td span {
    display: inline-block ;
    width: 37px;
    text-align: right;
}

[siepeltjuh]

Gezien de reacties toch nog wat meer over de achtergrond van de oplossing :-)

In de OP schrijf ik gemiddeld 150-200 medewerkers, dit blijkt in de praktijk meestal niet meer dan een stuk of 60 te zijn. Echter zijn er wel situaties waarbij er 150+ op de lijst kunnen staan.

Dit scherm is onderdeel van een groter (al werkend) geheel waarbij ook financiële verantwoording, activiteiten planning en meer komt kijken. Het is juist voor de urenverdeling van essentieel belang dat er een totaal overzicht is van zowel alle activiteiten en alle aanstellingen/resturen.

Dit is gewoon niet praktisch en de UX van dit type interface is verschrikkelijk.

Dit is feedback waar ik niet wat mee kan.

@R4gnax
Je hebt helemaal gelijk dat data-visualisatie een belangrijke kan zijn en het proces goed zou kunnen ondersteunen. Voor nu is dat echter een stap te ver en wil ik me zoveel mogelijk richting op het optimaal krijgen van het scherm in tabulair formaat.

[R4gnax]

siepeltjuh schreef op dinsdag 10 maart 2015 @ 00:26:
Dit is feedback waar ik niet wat mee kan.

@R4gnax
Je hebt helemaal gelijk dat data-visualisatie een belangrijke kan zijn en het proces goed zou kunnen ondersteunen. Voor nu is dat echter een stap te ver en wil ik me zoveel mogelijk richting op het optimaal krijgen van het scherm in tabulair formaat.

Als naast anderen ook mijn ervaring is, dat dit type oplossing waardeloos is, dan zet dat het reeds gemaakte punt nog wat kracht bij. Het engie 'wat jij er niet mee kunt', is dat je al vastgeroest zit in de gedachte dat het per sè een globale tabel moet zijn.

Wat betreft alternatieve oplossingen die 'een stap te ver' zijn en het optimaliseren van een oplossing die per definitie een kapotte gebruikservaring oplevert:

Dit is vast wel weer een idee wat vanuit management wegens budgetering afgedwongen wordt, of niet? Helaas is het nl. maar al te vaak zo dat daar korte termijn politiek bedreven wordt waardoor je op de lange baan veel meer kosten maakt om iets netjes afgerond en daadwerkelijk bruikbaar te krijgen, als het ooit al zover komt. (Zie ook: elk gefaald groot IT-project van de overheid over het afgelopen decennium.)

Maar goed; jij je zin. Je bent in elk geval voldoende gewaarschuwd.

[ Voor 8% gewijzigd door R4gnax op 11-03-2015 09:30 ]

[Verwijderd]

http://d3js.org/

[RobIII]

Verwijderd schreef op woensdag 11 maart 2015 @ 14:00:
http://d3js.org/

Het is wel fijn als je een beetje onderbouwing geeft als je ergens op reageert. Linkjes dumpen kunnen we allemaal...

[eXtreaL]

Aansluitend op André's antwoord:

Er ontstaan inderdaad constant repaints/reflows wanneer je scrollt. Dit komt doordat scrollLeft en scrollTop niet hardware accelerated zijn. Waar je naar zou kunnen kijken is de translate3D property, door hierbij de Z-as op 0 te zetten creëert je browser een nieuwe layer, en zal de GPU een groot gedeelte van de rendering afvangen.

Dit wordt ook wel de null transform, translate3D of translateZ hack genoemd. Let wel dat dit alleen op webkit browsers zal werken. Meer informatie: http://aerotwist.com/blog...and-layer-creation-hacks/.

[R4gnax]

eXtreaL schreef op woensdag 11 maart 2015 @ 14:51:
Aansluitend op André's antwoord:

Er ontstaan inderdaad constant repaints/reflows wanneer je scrollt. Dit komt doordat scrollLeft en scrollTop niet hardware accelerated zijn. Waar je naar zou kunnen kijken is de translate3D property, door hierbij de Z-as op 0 te zetten creëert je browser een nieuwe layer, en zal de GPU een groot gedeelte van de rendering afvangen.

Dit wordt ook wel de null transform, translate3D of translateZ hack genoemd. Let wel dat dit alleen op webkit browsers zal werken. Meer informatie: http://aerotwist.com/blog...and-layer-creation-hacks/.

Uhm ja; alleen maakt Webkit daarmee één gigantisch grote surface om door de compositor heen te gooien. Dat vreet echt flink wat geheugen. Het wordt zelfs al sterk afgeraden om een normale webpagina compleet accelerated te maken via deze composition layer hack; kun je nagaan wat het gaat doen met een gigantische table.

[Montaner]

Misschien dat ik iets mis, maar waarom geen pagination? Het is toch niet alsof iemand in 1 opslag 30k cellen kan bekijken. Ook zoveel scrollen is vervelend.

Er zijn wel wat JavaScript oplossingen waarbij alle data naar de client wordt gestuurd, en via JavaScript over verschillende pagina's wordt verdeeld. Zo heb je niet constant queries bij het openen van de volgende pagina, en dus direct resultaat.

Zelf wel eens extjs voor gebruikt. Weet niet wat de huidige status daarvan is...maar werkte wel mooi.

[Damic]

Je verliest links/rechts/boven/onder een stuk van je scherm.

[Feanathiel]

siepeltjuh schreef op zondag 08 maart 2015 @ 21:38:
[..]
De pagina wordt al snel 500kbyte groot
[..]
Met enkele optimalisaties is het me gelukt om het HTML-bestand van 4MB naar 450KB te verkleinen, zien jullie nog verbeteringsmogelijkheden?

siepeltjuh schreef op maandag 09 maart 2015 @ 23:17:
[..]
De html is verder geschoond: van 470 naar 299 KB:-)
[..]

Als de grootte van het bestand zo belangrijk is, waarom push je niet alleen de data naar de client (door bv. json icm. javascript te gebruiken)? Deze textwall is nergens voor nodig lijkt mij.