Experiment: CPU profile of the no-glint bench case - #59
Closed
johanrd wants to merge 4 commits into
Closed
Conversation
- The closure is part of the transform and report keys with Glint off too: the resolver reads an imported component's template to substitute its tag. - A `.ts`/`.js` module's co-located `.hbs` template (next to it or under `templates/components/`) and `/// <reference path>` targets are part of the closure. Without a tsconfig, relative imports still resolve. - The lockfile is found at or above the tsconfig directory (workspace root). A nested directory with its own package.json is not walked for project-wide inputs. - The tsconfig sha covers the whole `extends` chain and is re-validated against the file system; `backendKindFor` makes the same decision as `selectBackend` (a TypeScript 7 package that does not load falls back to ts6 in both). - A result computed after a Glint extraction threw is not cached at any level; the next run retries. - Long-lived hosts: the project-wide input list re-validates on the mtimes of the directories walked; an `index` probe watches the directory it lives in; trailing commas are removed outside strings only; file records keep import lists, not content. - The CLI computes report keys before the Glint preload and preloads the misses only; `dependencySha` is memoised per content under a static file system. `--help` names all three caches. Cowritten by Claude
…ndows separators Copilot review on #58: the string-safe JSONC scanner only skipped whitespace when looking for the closing bracket, so `{ "a": 1, // note\n }` kept the comma and JSON.parse failed after comment removal. The templates/components peer regex was POSIX-only, dropping the classic-layout peer from the closure on Windows.
The cache-key component loaded typescript-7's sync and ast modules (~30 ms) on every process, including replays that never need a backend. Whether the package loads is decided by its version and the Node version, so both are in the key and the package is only resolved.
Owner
Author
|
Closed on purpose — experiment only; see the workflow run and artifact. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Temporary experiment, closed on purpose. The
no-glint CPU profileworkflow buildsmainas control next to this branch (= release-0.9-fixes + the workflow), runs the bench'sno glintcase three times per side undernode --cpu-prof, prints wall times and the top self-time functions in the job summary, and uploads the.cpuprofilefiles as thenoglint-cpuprofilesartifact (open in Chrome DevTools > Performance > Load profile).Context: #58's bench comparison shows
no glint+13–17 % on CI twice while it is −1 % locally; the closure is not computed in that case (HVE_NO_CACHE=1), so the cause is unknown. Re-run from the Actions tab (workflow_dispatch) as needed.