perf(develop): skip query extraction if files are not dirty and schema didn't change

[pieh]

Description

Every time we invoke query running machine we go through extracting queries step. This adds quite a bit of unnecesary work (specifically on larger sites). This is particularly felt in query on demand mode where we enter query running state in response to user actions in browser (running queries that are not up date on navigation and link hovers). In one of sites this adds ~1s delay in on demand query running that is quite unnecessary and degrade experience.

Unknowns:

• as usual - investigate spots we clear schemaDirty and assess if this is safe (my gut feeling say that this is actually safe because schema rebuilding is governed by state machine, so there should be no "rogue" SET_SCHEMA events going on - but 🤷‍♂️ )

Related Issues

[ch19361]

[KyleAMathews]

🙌

[KyleAMathews]

Do we track the dirtiness of individual page components? Not necessary for this PR but if we do (or could), that'd be another speedup — only extract from dirty page components.

[pieh]

Do we track the dirtiness of individual page components? Not necessary for this PR but if we do (or could), that'd be another speedup — only extract from dirty page components.

We don't track it on extraction level - we do track extracted and merged query texts (for query invalidation purposes). Keep in mind that queries append used fragments so it's not just page components (or files with static queries) alone that needs tracking. This is solvable of course but is touching different parts of code (those would be internals of query extraction and not top level orchestrating layer)

[pieh]

From chat with @ascorbic

@ascorbic:
You need to be super careful with that change. There are going to be places where we assume that jumping to that machine will re-extract queries
Don’t forget static images either. They’re generated during query extraction
Also check anything that jumps earlier than query-extraction too
@pieh:
I also do wonder - I use existing dirtyFiles thingie - but there are multiple handlers for it - so I do wonder if each consumer need separate dirty flag (i.e. webpack vs extraction)
I think this one definitely needs test cases added

[KyleAMathews]

hmm ok given the above, it could just make sense to track the state of files in query extraction and skip files there that we know haven't changed.