Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perf: Pre-merge matching files patterns #101

Open
matwilko opened this issue Jul 13, 2023 · 1 comment
Open

Perf: Pre-merge matching files patterns #101

matwilko opened this issue Jul 13, 2023 · 1 comment

Comments

@matwilko
Copy link

In the same vein as #99, I think there's some up-front consolidation of config elements that could be done during normalization when adjacent elements share one or more files patterns in common (taking into account ignores as well).

(Adjacency might not even be required if it can be determined easily enough that two elements are completely disjoint (e.g. in the easiest case of ['**/*.a'] and ['**/*.b']), but I think that's something to leave for later.)

Given that configs are likely to have multiple elements that share some files patterns in common (due to importing configs from plugins that are applied to the same sets of files, e.g. many typescript related plugins will share { files: ['**/*.ts'] } in common), the potential for merging these configs together ahead of time presents the same benefits as merging through the global configurations - fewer elements in the array means less work per-file we get config for.

Even a partial match could be effectively merged by making the two elements disjoint, e.g.

[{ files: ['**/*.js'], something: {a: 1} }, { files: ['**/*.js', '**/*.ts'], something: { b: 2 }]
=>
[{ files: ['**/*.js'], something: {a: 1, b: 2} }, { files: ['**/*.ts'], something: { b: 2 }]

Again, happy to put together some code to flesh this idea out.

@nzakas
Copy link
Contributor

nzakas commented Jul 18, 2023

As with other suggestions, I'd be happy to evaluate a prototype.

Just as a reminder: we are potentially trading off additional complexity for performance, so I want to make sure the performance gain is substantial to offset that cost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants