Optimize AssetId.parse and cache _normalizePath

[gmpassos]

This simple optimization reduced the full build time of a project from 30 seconds to 24 seconds.

Original time:

Built with build_runner in 30s; wrote 31 outputs.

With the optimization:

Built with build_runner in 24s; wrote 31 outputs.

---

Statistics for the _normalizePath cache:

- Total calls: 16,828
- Computed: 4,723
- Uncached responses: 28%
- Cached responses: 72%
- Total strings in the cache: 4,723
- Total length of strings in the cache: 153,911

---

Dart SDK version: 3.8.2 (stable) (Wed Jul 16 08:06:06 2025 -0700) on "macos_x64"

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

[github-actions]

PR Health

Changelog Entry ❗

Package	Changed Files
package:build	build/lib/src/asset/id.dart

Changes to files need to be accounted for in their respective changelogs.

This check can be disabled by tagging the PR with skip-changelog-check.

[davidmorgan]

Thanks.

This is related to an improvement I wanted to try, so, I went ahead and tried it :)

This PR caches the path normalization, but I'm more interesting in caching the whole AssetId creation. This is because other places in the codebase optimize based on assuming that equal AssetIds are also identical, so those might benefit.

#4149

When making optimization it's necessary to be very careful with measurements, build_runner should really have some precise benchmarks that we run regularly, but I didn't add those yet, just a bit of tooling for benchmarks under _benchmark that I run manually.

Unfortunately, I suspect the 30s -> 24s you saw is not a real improvement: build_runner does a one off analysis of the SDK that it then caches, and this takes about 6s, my guess is what you're seeing is the effect of that cache. The file that gets written is .dart_tool/build_resolvers/sdk.sum. When I tried running repeatedly with and without your PR I didn't see such an improvement.

I was hoping that caching the full AssetId would give a performance improvement, but that also doesn't seem to make any big difference. It does reduce the asset_graph JSON size a bit though, as mentioned on the linked issue, so it's worth investigating further :)

tl;dr: probably I need to set up some proper (accurate!) benchmarks before we can make this type of optimization with sufficient confidence we're going in a good direction :) ... filed #4150 for that.

[davidmorgan]

Closing as I think we'll want to revisit this after adding fine benchmarking.