Figure out a better way to determine unique columns

[cball]

Since the column definition essentially doubles as a table cell, to determine the unique columns all column definitions are kept in an array and then uniqued by name. This gets not ideal when we have a really large dataset we're working with.

[BrianSipple]

This seems like it might be similar to what Ember.computed.uniqBy (available as of 2.7!) is designed for. But are you thinking of a different data structure altogether?

[BrianSipple]

Assuming we still want to keep the same structure, though, what we could do is have the function first sort all columns by headerName, then reduce over the sorted list -- only taking an item if its headerName is different than the previous item's headerName.

I'm not sure if that's what uniqBy would be doing under the hood already, but this would at least guarantee that we get the entire operation down to the time complexity of Array.prototype.sort (O(n log n) in Firefox and usually O(n log n in Webkit) -- but we're totes n^2 atm 😜 ).

I have a branch here demonstrating this, which actually abstracts that idea out into its own util. I could certainly PR it (with a test!) if this is the improvement you had in mind (Doing a few timing tests on the dummy app shows a pretty big speed up, fwiw).

[cball]

I know of at least 1 project using this that is stuck on 1.13, so I think the util approach is the best bet for now.

Just for background, I was attempting to make the column definitions completely template driven, and using blocks to override cell behavior. That turned out to be great for simplicity and ergonomics but less great for things like determining unique columns. Once the hideOffscreenContent is enabled, we're running this unique function as cells are being added/removed, which is slowing things down.

It's possible that there is only so much that can be done here, which would force moving to separate column definitions, but I think we should definitely pull in what you have.