Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[atable] poor performance when rendering #189

Open
agritheory opened this issue Nov 13, 2024 · 1 comment
Open

[atable] poor performance when rendering #189

agritheory opened this issue Nov 13, 2024 · 1 comment
Assignees

Comments

@agritheory
Copy link
Owner

Using a 28x53 table loading takes about 8 seconds in FAB customer application

@Alchez
Copy link
Collaborator

Alchez commented Nov 22, 2024

@agritheory Okay, so I looked into this, and here's what I've found:

  • Although Vue can handle DOM changes pretty efficiently, performing DOM manipulation adds up and can still generally be expensive.
    • For example, trying to render a 25x150 table (3750 cells) in the ATable default story - with minor custom formatting - took 2.5 seconds.
    • I'm not sure why a 28x53 table (1484 cells; 60% fewer cells) is taking ~5 seconds, but I'm guessing it's also dealing with a lot of DOM manipulation.
  • Vue recommends some general optimization tips while creating an application, and one of them is to virtualize large lists.
    • Virtualizing lists sounds like a memory technique that limits processing to a small portion of the dataset, both visually and in-memory.
    • Vue suggests using vue-virtual-scroller (by the same guy who made Histoire) to apply virtualization, but there's also a VueUse composable that does the same (and seems to be more modern and less buggy than the recommended one, although with fewer features).

I tried implementing the VueUse offering into the Histoire story as a POC, but I couldn't get it to work correctly. The other approach is to try to implement this directly at the ATable-level, which would have it work automatically for all tables, but that's a fair amount of work as well.

What do you think? And where should we place this in the priority list?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants