Lots of jank caused by inefficient `_detailsObj()`

Open
#141 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
typescript
Domain
frontend, performance

Research direction

Start at _detailsObj(), which is called by render() for each considered row, and trace the public API calls used to build its informational objects. Reproduce the Firefox/DataTables 2.2.2 scenario with about 2,800 rows and compare the render() and no-render() timings. Done means preserving the details renderer behavior while reducing the blocking time during the paging-length change.

Written by the indexing model from the issue text.

Description

Scenario: I'm using Firefox, Responsive 3.0.4, and DataTables 2.2.2 with a table of ~2800 data rows and something like this simple responsive configuration:

{
  // ...
  responsive: {
    orthogonal: 'responsive',
    details: {
      type: 'inline',
      renderer: () => false,
      display: (row, update, render) => {
        render();
      },
    },
  },
}

When I tell DataTables to show all rows via the paging length dropdown, it takes ~6.4 seconds to complete. During that entire time everything on the page is unresponsive. If I comment out render(), it only takes ~1.9 seconds to complete.

Digging into the code I noticed that render() calls a _detailsObj() which is what generates the informational objects passed to details.renderer(). From my testing, it seems like the bulk of the slowdown comes from the generating of the object property values (as opposed to the $.map() or object creation itself). I noticed that _detailsObj() is using public APIs to do its information gathering, which I believe is the source of the slowdown.

Seeing as how _detailsObj() is a hot function when you have a large number of rows being considered, would it be possible to have it use internal/private logic instead?

Currently to work around this issue I am having to patch DataTables to pass the table instance to my display() (as an extra parameter) to be able to reach into DataTables internals so I can avoid calling the expensive render(). With that I am back to ~1.9 seconds to render all of the rows.

Dominant language
TypeScript
Stars
151
Forks
91
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DataTables/Responsive

All issues in DataTables/Responsive

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.