Drastically faster templating approach #317
Conversation
there is no need to clone() here, it creates a memory leak as it's not attached the to DOM and therefore isn't removed by remove()
Trigger an event when columns are toggled on or off
The current templating approach is really inefficient, as it recursively loops thru every passed available variable for substituion and applies a regex for each one. It's much faster to initially parse the template and then only process those strings which are actually present in the template. This revised implementation both caches the parsed templates and then only processes the string which are present. The performance improvement is quite drastic, especially with large tables. A large table was previously taking 15s to render in Chrome, now takes less than 1s with this approach
|
Any chanche this fill be merged with the main branch? Seems nice to speed up rendering of large tables! |
|
Is this project still active? I'm using the library, it's awesome, but I don't see any new commits (but many new pull requests). |
|
I have recently verified the pull request, but it seems not to work correctly in any situation. The info footer |
|
the problem is a nested template string rather than add yet another level of recursion which would be repeated for every templated string, what do you think about refactoring this template string into the common templates definition? |
rather than needing to recursively process every string, move the templated string for infos into the template definitions
|
with the small dataset in the demo, it's taking 36ms to render with the old approach and 20ms to render using this new approach |
added buttons to append 10, 100 and 1000 rows with logging of rendering time (on screen and to console)
|
I have updated the demo with more append options (10 ,100 and 1000 rows) and logging render time to both the browser console and on screen using Chrome 55, win10 x64 new approach just testing the new approach, appending extra context IE 11 |
don't set the replacement value to null when a property doesn't exist
added back in the old method and evaluate the template string using both approaches, log out to console any different results found
|
I have added a test which just compares the output from both the new and old approaches. I found a problem will null being returned when a property didn't exist. The old approach left the missing properties in as the template string, see the {{ctx.style}} below from the demo page
|
refactored functions out from string and array protoypes included appendRow changes from rstaib#285 (50% faster in Chrome, 10% Edge, 15% FF)
This reverts commit cef18bc.
remove prototypes from string and array merge in appendRow rstaib#285 improves Chrome 50%, FF 15%, Edge 10%
|
Refactoring the functions out of the String prototypes into functions saved 400ms in IE and Edge Refactoring out Array didn't make so much of a difference tho, but it's best practise #148 Including #285 speed up Chrome by 50%, Firefox by 15% and Edge by 10%, IE still sucks |
no longer needed since appendRows
|
The remaining performance problems in Edge are simply browser problem |
|
What is the problem stopping this from being merged for this long? |
|
+1 |
The current templating approach is really inefficient, as it recursively loops thru every
passed available variable for substituion and applies a regex for each one.
It's much faster to initially parse the template and then only process those strings which are
actually present in the template.
This revised implementation both caches the parsed templates and then only processes the strings which are present.
The performance improvement is quite drastic, especially with large tables. A large table was previously taking 15s to render in Chrome, now takes less than 1s with this approach