Skip to content

[idea] Minimal modifications in update_keyed_each #6603

Closed as not planned
Closed as not planned
@hbirler

Description

@hbirler

Describe the problem

The problem that update_keyed_each needs to solve seems really similar to the problem hydration needs to solve, i.e. "How do we reorder nodes with the minimal number of operations possible?"

Describe the proposed solution

Maybe update_keyed_each could also benefit from the longest increasing subsequence logic from the hydration pull request #6395. Maybe both subsystems could reuse the same code, potentially reducing the code size and increasing keyed-each performance.

I currently don't have a lot of free time so I thought this might be interesting for someone else willing to look into it.

Alternatives considered

I have not fully analyzed the current update_keyed_each logic so it might be that it already does minimal operations given its requirements. In that case, I am sorry to have bothered you all :)

Importance

nice to have

Metadata

Metadata

Assignees

No one assigned

    Labels

    compilerChanges relating to the compilerperf

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions