Performance issue when displaying translated tabularised data sets
Closed this issue · 14 comments
I'm submitting a bug report
- Library Version:
1.0.0-rc.1.0.0
Please tell us about your environment:
- Operating System:
Windows 10 - Node Version:
5.11.1 - NPM Version:
3.10.2 - JSPM Version
JSPM 0.16.34 - Browser:
Only tested Chrome & IE 11 - Language:
ESNext
Current behavior:
Tables with 120 rows and 5 columns of translated data causes the browser to slow down dramatically:
In both cases I've experienced this I'm using a 'shared' dateTimeFormatter #100 to get performance gains there. It seems to me that the normal i18n text translation is what is slowing it down though:
Expected/desired behavior:
The browser should be able to function without stressing so much to display 120*5 translations. As a work around I have implemented pagination but one of the views is an event log where they'd probably want to see a number of events on a page.
Actually. I have an export function which is translates and exports 1000s of rows of data so I think this might be more a binding related issue and may not be an i18n thing specifically.
Oh it might help to say that I'm using the t binding behaviour when displaying the table. Is there a difference between the using the t attribute vs binding behaviour vs value converter?
@zewa666 Please look into this.
@AdamWillden We usually recommend using ui-virtualization for scrollable or paginated tables of data. It's far more efficient. See the same-named repo here for more information.
@EisenbergEffect actually I did try it (aurelia-ui-virtualisation) and I couldn't get it to work... I didn't raise an issue though, I just abandoned ship.
Closing this for now. Please follow up on the virtualization library.
@AdamWillden can you come up with a simplified example for me to try this out. Would be interested to see whether we can do something about this even without the virtualization lib
@zewa666 welcome back off of holiday (I read somewhere you'd gone for a week). Hope it was nice!
I will sort something out as I do think there is probably something that can be done to get some improvement here. 3-4 seconds is a long time given the amount of data.
@zewa666 please see attached: i18n-perf-issue.zip
The issue is with the binding behaviour after all. Try increasing the rows from 200 to 1000. You will see a big difference between the two (binding behaviour vs value converter).
Again this might be more an issue with the binding system than i18n. I'll leave it to the professionals.
thanks @AdamWillden, I'm pretty sure @jdanyow could be interested in this as well
@AdamWillden of course Bindings will have to always be slower since they include both way bindings and the Event Aggregator used additionally adds more load to it. Funny enough I think the attribute translation should be the fastest, since it performs raw DOM mass operations.
But still this might be used as a nice example to try improve the BB performance
the behavior does add more overhead because it's doing two things: rewriting the expression and attaching the signal.
Once #107 (comment) is implemented it should become quite a bit faster because the expression rewrite will only happen once per expression instead of once per binding instance. Give it a try and let me know if that speeds things up.
Ok great, i planned that anyway as next Task. Will come back to both of you wether it helped
I look forward to hearing from you :-) I understand the binding behaviour is doing a lot more, I was surprised at the sizeable difference between them though.
@AdamWillden yep the proposed fix from @jdanyow did solve the problem. Rendering 1k of rows is now much faster. Will be available with the next release
@zewa666 great news :-) thank you!