Blueprint: Table performance issue with massive data

Created on 27 Dec 2016  路  19Comments  路  Source: palantir/blueprint

  • __Package version(s)__: 1.2.0
  • __Browser and OS versions__:

Issues

  1. when rendering a huge amount of data ( 50+ rows with 44 columns ), the performance of scrolling (both horizontal and vertical ) is significantly slow

  2. I notice that if the height of the table is small ( as shown in the documentation example), this issue is gone. However if my table height is as high as the browser window, this will happen.

Just want to know if there is any optimization tips on the table?

performance P1 table

Most helpful comment

@tgreenwatts Issues described here in comments were not resolved. I'm experiencing the same performance issues. Why is this issue closed?

Even with running in production mode, table of size 1400x400px (only 18 rows visible!) containing only 7 columns and only (yes, only, because tables are meant for large data) about 1200 rows, it's unusable, scrolling or selecting is very slow or worse, sometimes when scrolling, some of the cells get rendered, some of them not.

Oh and I didn't mention the CPU load. Horrible. All macbooks spins up immediately like they're trying to fly away.

All 19 comments

Performance is much-much better when you build app in production mode
http://dev.topheman.com/make-your-react-production-minified-version-with-webpack/

oh yes what @avin said is the greatest React optimization tip of all time. React dev mode is noticeably slower than production mode because it does lots of extra runtime validation that is useful for development but shouldn't be needed on your prod site.

@avin @giladgray Yes I noticed that, changing to production model makes it significantly faster

But when rendering a large viewpoint, the speed is still noticeably lagging

There are two things at play here: how the table renders itself (which is very complex to begin with), and how you store your data. Trying to determine where the slowness is... I'm curious how you're using the table. @ripitrust would you be able to share your setup code?

@giladgray Thanks for the reply

currently I am passing datas into a wrapper component :

<Table data={servers} />

in this wrapper component I render the actual blueprint table:

render(){
        const { _renderCell } = this;
        const { data, tableHeight } = this.props;
        const numOfServers = data.length;

        const keys = this._getKeyArray(data);

        return (

            <div style={{height:tableHeight}}>

                <Table numRows={numOfServers}
                       style={{height:tableHeight}}
                        defaultColumnWidth={100}>

                    { keys.map( function(key, index) {

                        return <Column name={key} key={index} renderCell={_renderCell(keys)}/>

                    })}

                </Table>
            </div>
        )

 }

@ripitrust what does renderCell look like? Might be easier if you posted a gist on gist.github.com

I also have performance issues with my table. Don't get me wrong, your virtualizing works really well, so it's not that noticeable but the CPU load gets pretty high.
It seems that renderCell is getting called a lot when scrolling and I was wondering if there's a way to hint the table component, that my data hasn't changed. I used data versions passed as a prop (incrementing number, timestamp, hash, ...) in a similar case before. The table would then only call renderCell if the cell gets close to the viewport.

We're going to start investing in table rendering performance in the next few weeks; I think @gscshoyru will have some bandwidth to investigate.

I think something simple like how https://facebook.github.io/fixed-data-table/ and other data tables work where you limit the amount of currently rendered rows too a specific size (say 15 rows or what not) and then render just 15 rows, and as you scroll remove out of view rows and show newly in view rows.

We already do that. It's called virtual rendering, it's not that trivial. We still have many improvements to do around performance, so look out for updates soon

@ripitrust I'm chiming in a bit late but I've noticed that rendering performance for a large table is rather degraded on Chrome, but not on Safari or Firefox. Can you confirm?

@michael-yx-wu I would say it is slightly slower in Chrome (macOS) than in safari, just barely noticeable

Stumbled upon this excellent React talk about virtualization and windowing in general: https://bvaughn.github.io/forward-js-2017/

I think we can close this and reference it in future more targeted perf discussions

ehh I think the discussion thread is valuable & good for searchability. I'd like to keep it open

We've done a lot of work in terms of perf here, I'm going to close this, it's still searchable, but we can open a new more targeted ticket for new perf concerns

@tgreenwatts Issues described here in comments were not resolved. I'm experiencing the same performance issues. Why is this issue closed?

Even with running in production mode, table of size 1400x400px (only 18 rows visible!) containing only 7 columns and only (yes, only, because tables are meant for large data) about 1200 rows, it's unusable, scrolling or selecting is very slow or worse, sometimes when scrolling, some of the cells get rendered, some of them not.

Oh and I didn't mention the CPU load. Horrible. All macbooks spins up immediately like they're trying to fly away.

as of 2021 the performance is still pretty bad; wonder if this is really what palantir uses in production or they simply dont display lots of cells at once hmmm e.g. 100,000 cells

Was this page helpful?
0 / 5 - 0 ratings

Related issues

havesomeleeway picture havesomeleeway  路  3Comments

sunabozu picture sunabozu  路  3Comments

ernestofreyreg picture ernestofreyreg  路  3Comments

shahzeb1 picture shahzeb1  路  3Comments

tomzaku picture tomzaku  路  3Comments