Closed Piezoid closed 3 years ago
cadriel
commented
3 years ago Yep. This is likely due to implementation and the changes recently to do with filtering, and command clicks.
Really the data should be appended once without the need for additional rendering on already appended items.
I'll take a look at making some adjustments here for an upcoming release.
cadriel
commented
3 years ago Ok, so there was some nasty things going on here;
The issue isn't having 1000 items in the DOM, but having to remove / add them IS. I have steps 1 and 2 sorted, and am working on a solution for 3.
cadriel
commented
3 years ago @Piezoid
I have a fix in place. Would you be able to run your tests on the attached test build? If you come up with no issues - I'll merge. Thanks! fluidd.zip
Piezoid
commented
3 years ago I have a fix in place. Would you be able to run your tests on the attached test build? If you come up with no issues - I'll merge.
Great, thanks! I can confirm that it's much more fluid now, with the virtual scrolling.
The issue isn't having 1000 items in the DOM, but having to remove / add them IS.
Yes, the issue was updating/rendering all of them for inserting a single entry.
I think 1. and 3. were the most important improvements, ad they reduce the size of DOM updates which was the point of friction. I was a bit concerned about the added complexity and dependencies of virtual scrolling, but since you went for it, I guess it's fine.
One potential improvement would be to batch multiple insertions in one update. Currently, it seems that only a single entry can be added per DOM update.
When the console history is full (1000 entries) new entries are displayed very slowly and the frame time reach ~1s on Chrome and Firefox. This is most obvious with big outputs (
DUMP_TMCor tuning tower with a spiralized contour) Profile screeshotReducing
config.CONSOLE_HISTORY_RETENTIONto 100 solved the problem, confirming the O(n) render time theory. The DOM view shows that all entries and their container gets updated (pink flash) each time a new one is added.I've tried to key the
ConsoleEntryWidgetsv-forwith a monotonic key, instead of the dequeue's indices, to help the diffing algorithm avoid shifting the content of all entries. This allows to usev-onceinside console entry, which was not working before because of the content shift. It helped a bit (frame time dropped to 400ms), but still very slow.Draft patch
```diff diff --git a/src/components/widgets/ConsoleEntryWidget.vue b/src/components/widgets/ConsoleEntryWidget.vue index d49f9eb..075c6ab 100644 --- a/src/components/widgets/ConsoleEntryWidget.vue +++ b/src/components/widgets/ConsoleEntryWidget.vue @@ -1,5 +1,5 @@ -Profile screeshot
Possibly, implementing a virtual scrolling would help the most, but not being able to avoid rendering of all entries is cumbersome.