137818 2014-10-17 07:21:42 -0700 [meta][EFL] Speedup incremental builds 2017-03-11 10:32:23 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 137605 137949 137953 138464 1 ossy webkit-unassigned gyuyoung.kim mcatanzaro ossy oldest_to_newest 1042371 0 ossy 2014-10-17 07:21:42 -0700 Now the incremental build takes too long if you touch only one cpp. In my opinion it slows down the development, so we need to speed up it. Some ideas: - Don't run cmake, just run ninja directly --> the developer can do it, no fix needed - Reduce always running targets to zero, simiar to GTK ( bug130075 ), now only forwarding header generator runs 4 times always, and it takes ~ 5-6 seconds - use gold linker (really faster) - be able to disable API tests easily (87 relinking --> 9 relinking) My quick and dirty fixes for these task reduced the incremental build from ~2 minutes to 10 seconds. I'm going to add subtasks to the depends on list soon and upstream fixes. 1043436 1 ossy 2014-10-22 06:35:19 -0700 (In reply to comment #0) > - Don't run cmake, just run ninja directly --> the developer can do it, no > fix needed We can do it automatically too, new bug report for it: bug137949 performance win: ~ 0.5 minutes > - Reduce always running targets to zero, simiar to GTK ( bug130075 ), > now only forwarding header generator runs 4 times always, > and it takes ~ 5-6 > seconds It can cause problems like mentioned here: https://bugs.webkit.org/show_bug.cgi?id=137394#c6 > - use gold linker (really faster) new bug report for it: bug137953 performance win: ~ 1 minute > - be able to disable API tests easily (87 relinking --> 9 relinking) It is already possible with build-webkit --cmakeargs="-DENABLE_API_TESTS=OFF" performance win: ~ 1 minute If we use these 3 optimizations together, the incremental build takes only 10 seconds instead of 1m51s seconds. 1286177 2 mcatanzaro 2017-03-11 10:32:23 -0800 Closing this bug because the EFL port has been removed from trunk. If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.