2015-12-02 12 views
10

Ich habe Probleme mit der Leistung beim Rendern großer Datentabellen mit Aurelia.Rendern großer Datentabellen mit Aurelia

Selbst bei mittelgroßen Tabellen (20x20) erreiche ich nicht weniger als 200ms für Chrome, MS Edge dauert ~ 800ms und IE11 dauert ~ 2s. Die 200ms sind auch ein Problem, wenn Sie (virtuelles) Scrollen hinzufügen möchten. Die Verarbeitungszeit erhöht sich mit der Anzahl der Bindungen pro Tabellenzelle. Ich habe eine (example) zusammengestellt, die 'css', 'class' und natürlich den Zellinhalt bindet.

<table class="table"> 
    <tbody> 
    <tr repeat.for="row of rows"> 
     <td repeat.for="column of columns" css.bind="getCellStyle(column, $parent.$first)" class.bind="getCellClasses(column, row)"> 
     <template replaceable part="cell-template"> 
      <span>${getCellText(column, row)}</span> 
     </template> 
     </td> 
    </tr> 
    </tbody> 
</table> 

Irgendwelche Ideen, wie ich die Leistung verbessern könnte?

Basierend auf ersten Vorschlägen habe ich versucht, die verschachtelten Wiederholungen zu vermeiden, aber das ist in meinem Fall nicht möglich, da sowohl Spalten als auch Zeilen dynamisch sind.

+0

[Ui-Virtualisierung] (http://aurelia.io/ui-virtualization)? –

+0

Die Frage war die Optimierung für das Rendern sichtbarer Tabellenzellen. Aurelia ui-virtualization hilft, wenn es viele unsichtbare Zeilen gibt. – reinholdk

+0

ohhhhhhhhhhh ... –

Antwort

9

Großartige Frage, auf die wir uns in letzter Zeit stark konzentriert haben.

Vermeiden Sie Verschachtelungswiederholungen, wenn es eine Tonne Daten gibt. Wir arbeiten an einer Leistungsverbesserung für dieses Szenario, die die Leistung für dieses Szenario durch das Abrollen der Vorlagen dramatisch verbessert, aber noch nicht zur Veröffentlichung bereit ist.

Zweitens, verwenden Sie einmalige Bindungen, wo immer es möglich ist. Dies wird jegliche Eigenschaftsbeobachtung und Array-Mutationsbeobachtungsaufwand eliminieren.

<table class="table"> 
    <tbody> 
    <tr repeat.for="row of rows & oneTime"> 
     <td repeat.for="column of columns & oneTime" css.one-time="getCellStyle(column, $parent.$first)" class.one-time="getCellClasses(column, row)"> 
     <span>${getCellText(column, row) & oneTime}</span> 
     </td> 
    </tr> 
    </tbody> 
</table> 

12/13/2015 EDIT

Die bevorstehende Veröffentlichung hat zwei Änderungen, die die Renderzeit von großen Gitter halbiert wird oder sogar noch weniger. Eine der Änderungen verbessert die Effizienz von Einwegbindungen (bei weitem der am häufigsten verwendete Bindungsmodus) und die andere ändert einige Bindungsarbeiten bis nach dem anfänglichen Rendern. Dies macht die Verwendung von oneTime und oneWay genauso schnell in Bezug auf den anfänglichen Rendervorgang. Mehr Informationen zu diesen Verbesserungen hier: http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/

Demo hier: http://jdanyow.github.io/aurelia-dbmonster/

+0

Danke, lloking nach vorne auf die Veränderung. Wenn Sie jedoch oneTime verwenden, wird die Tabelle nicht mehr neu gezeichnet, wenn sich der Datensatz (Spalten) ändert. Wie trigger ich ein Neuzeichnen der Ansicht? Lies einfach das "Signal" -Bindungsverhalten in deinem tollen Blog: http://www.danyow.net/aurelia-binding-behaviors/, das hier helfen könnte, aber das Signal scheint nicht von dem oben erwähnten Performance-Fix zu profitieren. – reinholdk

+0

whoa, wo ist das "& oneTime" im Wiederholungsausdruck dokumentiert? Ziemlich schick. –

-2

Sie Ihre Arrays miteinander kombinieren, wie erwähnt.

+2

Dies liefert keine Antwort auf die Frage. Um einen Autor zu kritisieren oder um Klärung zu bitten, hinterlasse einen Kommentar unter seinem Beitrag. - [Aus Bewertung] (/ review/low-quality-posts/10428922) –

+0

@MikeB Ich bin mir ziemlich sicher, dass es direkt auf seine Frage antwortet. es sagt ihm buchstäblich genau, was zu tun ist. –

+0

danke für die Rückmeldung, aber ich fühle, dass die zur Verfügung gestellte Antwort nicht die hier genannten Richtlinien erfüllt: http://stackoverflow.com/help/how-to-answer –