Draft
Conversation
5224cd2 to
4904c84
Compare
950fc6d to
41eed91
Compare
bb39565 to
2a21507
Compare
6233816 to
f858659
Compare
71db1d0 to
a2c371f
Compare
7364b4b to
cf43f0c
Compare
252b966 to
874a943
Compare
RandomByte
commented
Feb 18, 2026
df275e5 to
0345502
Compare
RandomByte
commented
Mar 5, 2026
9fc2509 to
20ba653
Compare
20ba653 to
9fc2509
Compare
9fc2509 to
940376d
Compare
9197670 to
44d1107
Compare
44d1107 to
d7c402c
Compare
Member
|
Rebased onto origin/main |
…ly some dependencies, not all) `+` Fix some typos in comments
`+` Extend FixtureTester to assert seen projects (not only built projects)
`+` Fix some copy/paste leftovers ("cleanDest: false")
`+` Replace console.log with @ui5/logger Log
* Add test for "ui5 --version" * Add test for "ui5 build" (currently testing a TS application) Currently, those tests are not included in any CI pipeline and also need a manual "npm install" (no node_modules included yet).
+ Include "npm install" in test runtime
+ Refactor test environment for better reuse + Extend typescript test to cover Incremental Build
+ Add "application.a" (Javascript project fixture)
…ently FAILING) + Refactor "ui5-tooling-modules" test
aa3a2c1 to
17bfe1c
Compare
…gistry.flush Split upsertResources into two phases: concurrent I/O resolution via Promise.all (getIntegrity, getSize, matchResourceMetadataStrict) followed by serial tree mutation. This avoids sequential file reads when processing many resources. Pre-resolve getIntegrity and getSize for all pending resources concurrently via Promise.all before the serial tree-mutation loop. This avoids redundant sequential I/O across the triple-nested directory x tree x resource loop.
Restructure updateIndices() into 3 phases: collect all unique paths across request sets, batch-fetch in parallel via Promise.all, then process synchronously from cache. Also parallelize refreshIndices() node processing since SharedHashTree operations schedule atomically into the TreeRegistry.
Add unchangedNodes Set in TreeRegistry.flush() to track resource nodes already confirmed unchanged via matchResourceMetadataStrict. Subsequent trees sharing the same node skip the full comparison and only check tags, eliminating N-1 async calls per shared resource across N trees.
Overlap stage cache I/O by prefetching metadata for the next task while the current task is executing. This reduces idle time between sequential task executions in warm-cache builds.
Add structured timing and counters to identify I/O hotspots in the build cache validation flow. Instrumentation covers refreshIndices, updateIndices, flushTreeChanges, TreeRegistry.flush phases, and matchResourceMetadataStrict. All gated behind @ui5/logger perf level or UI5_CACHE_PERF env var.
Add perf-level timing to the build orchestration layer to identify the ~6.5s gap observed in warm-cache builds between source index initialization and per-project cache validation. Instruments: - getRequiredProjectContexts (total + per-project context creation) - prepareProjectBuildAndValidateCache (getDependenciesReader vs cache) - #flushPendingChanges (source index vs dependency index updates) - ProjectBuilder.#build per-project timing
Defer source index initialization from ProjectBuildCache.create() to a separate initSourceIndex() method, allowing BuildContext to initialize all project source indices concurrently via Promise.all instead of sequentially in the dependency discovery loop.
During dependency index updates, the cache proxy reader eagerly called cacache.get.info() for every byPath() request, even though the callers (hash tree upserts) only need resource metadata. With 2550+ parallel calls, this created severe filesystem I/O contention (~2.2s). Defer the cache path resolution to first content access using a lazy singleton promise pattern. Also replace O(n) Array.includes() with O(1) object property lookup and fix the size/byteSize parameter mismatch. sap.ui.layout updateDependencyIndices: 2466ms -> 59ms Total warm-cache build: 2.85s -> 315ms
…ing cache writes Track integrity hashes from restored stage metadata in a Set and skip cacache.get.info() calls for resources already known to be in CAS. Reduces cache write time from ~1,400ms to ~100ms for stale-cache builds by eliminating ~15,000 redundant CAS existence checks.
… import On first CLI invocation, #importStages treated all restored stage resources as "changed" because #currentStageSignatures was empty. This caused ~3000+ resource paths to be propagated to dependents, triggering expensive updateDependencyIndices calls (~108ms total). The imported stages represent the already-cached state, not actual changes. Skip writtenResourcePaths accumulation when this is the initial import (empty #currentStageSignatures), since dependents' dependency indices were restored from the same persistent cache.
…pagated When restoring from cache, dependency indices are already populated via BuildTaskCache.fromCache. If no dependency changes were propagated from upstream projects, the cached indices are already correct and _refreshDependencyIndices can be skipped entirely. This avoids fetching ~2738 resources per dependent just to confirm nothing changed, saving ~130ms on warm-cache builds.
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
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.
Implementation of RFC 0017 Incremental Build
This PR supersedes previous PoC: #1238
JIRA: CPOUI5FOUNDATION-1174