Lots of jank caused by inefficient `_detailsObj()`

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.

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.