Optimize the update of a has-many relationship.

[pieter-v]

Analyzing a performance issue in our application, I noticed that updating an existing relationship (with a large number of records) is very expensive. A lot of time is consumed in Array.splice.
By changing the order: first remove all records in reverse order and then add all records in correct order, is a quick win.
See output of test application that adds each time 200 records to the same relationship until 20.000
Test application can be found ember-has-many-update

Before

After

[btecu]

You can also remove the setForArray function.

[pieter-v]

@btecu done ;-)

[snewcomer]

This seems like a great idea! I kept thinking that this might result in slightly different behaviour but then I contradicted myself. Nice job. 👍

[runspired]

Can you port the test app to being a route in our relationship performance test app?

[pieter-v]

I'm looking into it

[pieter-v]

@runspired I just could not figure out how to automate the access to a second route. I could of course chain it to the logic of the existing application route, but then things will quick get messy if more scenarios are added.

[runspired]

@pieter-v don’t worry about automating the test itself I can add that part fairly easily :)

[pieter-v]

@runspired I've updated the relationship performance test app.
I also added 'performance.measure' lines, so that they show up in the Performance Tab - Timings section of Chrome

[pieter-v]

I further analysed the update of a relationship, and noticed that a lot of time is spend in OrderedSet.delete and more precisely in list.indexOf(obj). Since in this scenario the position of the object is known, I added a OrderedSet.deleteWithIndex (similar to OrderedSet.addWithIndex)

[igorT]

@runspired are we good to go here?

[runspired]

@igorT all we need to do is rebase so that the new performance test is run so that we can see the output from this change, I am otherwise 👍 on merging this.

[pieter-v]

@runspired @igorT rebase done

[runspired]

• Materialization sees a 26ms improvement in setup prior to materialization
• Add Children sees a 3847ms improvement, half in initial setup and half when pushing the update
• unload sees a 2755ms improvement in early setup phases (prior to unload)
• destroy sees as 2500ms improvement in early setup phases (prior to destroy)