[TIMOB-26761] iOS: Checking every single file modification makes larger apps really slow
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | High |
| Status | Closed |
| Resolution | Duplicate |
| Resolution Date | 2019-07-26T11:45:06.000+0000 |
| Affected Version/s | Release 6.2.1, Release 8.0.0, Release 7.5.0 |
| Fix Version/s | n/a |
| Components | iOS |
| Labels | alloy, build-time, engSchedule, ios |
| Reporter | Hans Knöchel |
| Assignee | Alan Hutton |
| Created | 2019-01-23T17:32:05.000+0000 |
| Updated | 2019-07-26T11:45:06.000+0000 |
Description
This one is no regression and was likely never considered as a bug, but it's quite simple: When re-building an iOS app - even without any change, the build takes like 20seconds. Ruffly 10 seconds of that are caused by a "build state check" that validated *every* single file to see if it changed, causing thousands of logs in larger projects like ours.
A simple way to fix this would be to not check every file, but curate a blacklist of changed files that can be compared (like with a hash). If I remember correctly, something very similar is already done for Hyperloop right now.
Example of this log:
[TRACE] No change, skipping /Users/hans/Documents/dev/myapp/myapp-titanium/build/iphone/build/Products/Debug-iphonesimulator/MyApp.app/node_modules/date-fns/is_today/index.js
Only partly related: The same can be applied to Alloy, where the "alloy compile" command is executed on every incremental build, even if no files change. There is a command for conditional Alloy compiling which LiveView also use, so Alloy should make use of it internally as well.
Closing as this was addressed in TIMOB-27043