www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Reducing build times of ldc-build-runtime

reply Jacob Carlborg <doob me.com> writes:
I'm working on the CI setup for iOS using Bitrise [1]. I'm currently 
hitting the 45 min build time limit. It takes around 11 minutes for 
building LDC itself and then running `ldc-build-runtime` times out, so 
I'm guessing it takes more than 34 minutes. The last completed object 
file is at the progress: 847/896, so it's almost complete.

Is there a way to reduce the build times? It looks like it compiles all 
files separately. Is it possible to compile multiple files at once? 
Perhaps that could reduce the build times. It also seems that there are 
four versions built: regular, debug, unittest and unittest-debug. Are 
all necessary? Can we avoid building some version(s)? Perhaps skip 
unittest and only build unittest-debug?

Since this is done using cross-compiling it might be possible to build 
the binaries on a different CI service and then trigger a build on 
Bitrise using their API to run the actual tests. But that would make it 
more complicated.

[1] https://bitrise.io

-- 
/Jacob Carlborg
Mar 17
parent reply kinke <noone nowhere.com> writes:
On Tuesday, 17 March 2020 at 20:09:54 UTC, Jacob Carlborg wrote:
 Is there a way to reduce the build times? It looks like it 
 compiles all files separately.
The regular libs are built all-at-once (by default), but the unittests require separate compilation (otherwise you need something like 24 GB of RAM). With ninja, you're using parallelization by default, but I'd still recommend to set the number of parallel jobs explicitly in the ldc-build-runtime cmdline. Each job should have about 2 GB of memory. What are the hardware specs for bitrise?
 Can we avoid building some version(s)? Perhaps skip unittest 
 and only build unittest-debug?
Sure, if the release unittests take too long to compile, then go ahead and exclude them for now. A simple variant is to invoke ldc-build-runtime as usual, but without `--testrunners`, and instead invoke `ninja -j<N> druntime-test-runner-debug phobos2-test-runner-debug` manually in the ldc-build-runtime.tmp directory.
 Since this is done using cross-compiling it might be possible 
 to build the binaries on a different CI service and then 
 trigger a build on Bitrise using their API to run the actual 
 tests. But that would make it more complicated.
Yeah, 45 minutes is pretty short (and 11 minutes to compile LDC very slow). An x86 simulator for Azure CI or so would be pretty much unrestricted (6h time-out...).
Mar 17
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2020-03-17 22:33, kinke wrote:

 The regular libs are built all-at-once (by default), but the unittests 
 require separate compilation (otherwise you need something like 24 GB of 
 RAM). With ninja, you're using parallelization by default, but I'd still 
 recommend to set the number of parallel jobs explicitly in the 
 ldc-build-runtime cmdline. Each job should have about 2 GB of memory. 
 What are the hardware specs for bitrise?
Not great: Processor Speed: 2.58 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 30 MB Memory: 4 GB
 Sure, if the release unittests take too long to compile, then go ahead 
 and exclude them for now. A simple variant is to invoke 
 ldc-build-runtime as usual, but without `--testrunners`, and instead 
 invoke `ninja -j<N> druntime-test-runner-debug 
 phobos2-test-runner-debug` manually in the ldc-build-runtime.tmp directory.
I'll give that a try. Thanks.
 Yeah, 45 minutes is pretty short (and 11 minutes to compile LDC very 
 slow). An x86 simulator for Azure CI or so would be pretty much 
 unrestricted (6h time-out...).
Yeah. This is what you get in the free open source plan. -- /Jacob Carlborg
Mar 18
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2020-03-17 22:33, kinke wrote:

 Yeah, 45 minutes is pretty short (and 11 minutes to compile LDC very 
 slow). An x86 simulator for Azure CI or so would be pretty much 
 unrestricted (6h time-out...).
With the free plan for closed source projects you only get 10 minutes for each build. That won't get you far. https://www.bitrise.io/pricing/teams -- /Jacob Carlborg
Mar 18
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 18 March 2020 at 16:25:56 UTC, Jacob Carlborg wrote:
 On 2020-03-17 22:33, kinke wrote:

 Yeah, 45 minutes is pretty short (and 11 minutes to compile 
 LDC very slow). An x86 simulator for Azure CI or so would be 
 pretty much unrestricted (6h time-out...).
With the free plan for closed source projects you only get 10 minutes for each build. That won't get you far. https://www.bitrise.io/pricing/teams
A bit off-topic, but how does it compare to other services like Azure Pipelines, GitHub Actions, BuildKite, etc. that support self-hosted runners? (Also the first two have free macOS runners and Windows runners.) From a quick look through the page they indeed offer many features tailored to mobile dev, but at least for work, I wouldn't choose a CI solution that doesn't offer support for self-hosting runners.
Mar 19
next sibling parent reply kinke <noone nowhere.com> writes:
On Thursday, 19 March 2020 at 10:22:31 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Wednesday, 18 March 2020 at 16:25:56 UTC, Jacob Carlborg 
 wrote:
 On 2020-03-17 22:33, kinke wrote:

 Yeah, 45 minutes is pretty short (and 11 minutes to compile 
 LDC very slow). An x86 simulator for Azure CI or so would be 
 pretty much unrestricted (6h time-out...).
With the free plan for closed source projects you only get 10 minutes for each build. That won't get you far. https://www.bitrise.io/pricing/teams
A bit off-topic, but how does it compare to other services like Azure Pipelines, GitHub Actions, BuildKite, etc. that support self-hosted runners? (Also the first two have free macOS runners and Windows runners.) From a quick look through the page they indeed offer many features tailored to mobile dev,
 but at least for work, I wouldn't choose a CI solution that 
 doesn't offer support for self-hosting runners.
For work, I wouldn't choose any cloud solution at all. E.g., Azure has been a major pain in the ass the last week - python.exe not in PATH for some hours/days, afterwards PRs and pushes not triggering builds automatically for 2-3 days, and after that, I've had to create a new 'service connection' via GitHub PAT in order to successfully upload artifacts to the GitHub releases again. In the meantime, the MS apt servers like to fail from time to time due to checksum failures (yes, always the MS ones), so that `apt-get update` fails etc. So if possible, I'd prefer to have an existing CI service be extended by a new iOS job, for a reduced maintenance burden. Azure's Mac VMs are quad-cores (unlike GitHub Actions for example, which only offer dual-cores; LDC compiles in under 4 mins) and ship with Xcode + simulators, see https://github.com/microsoft/azure-pipelines-image-generation/blob/master/images/macos/macos-10.14-Readme.md.
Mar 19
next sibling parent kinke <noone nowhere.com> writes:
CircleCI (also with quad-core Mac VMs) would be another option; 
they have some test-related docs: 
https://circleci.com/docs/2.0/testing-ios/
Mar 19
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2020-03-19 15:28, kinke wrote:

 So if possible, I'd prefer to have an existing CI service be extended by 
 a new iOS job, for a reduced maintenance burden. Azure's Mac VMs are 
 quad-cores (unlike GitHub Actions for example, which only offer 
 dual-cores; LDC compiles in under 4 mins) and ship with Xcode + 
 simulators, see 
 https://github.com/microsoft/azure-pipelines-image-generation/blob/master/images/macos/ma
os-10.14-Readme.md. 
I had plan to setup a CI pipeline for testing on physical devices. See my reply to Petar [1]. I have actually not tested on the simulator yet. [1] https://forum.dlang.org/post/r50det$aah$1 digitalmars.com -- /Jacob Carlborg
Mar 19
parent reply Kagamin <spam here.lot> writes:
You mean that CI compiles LDC and druntime right on iphone? I 
thought CPU clock looks like arm, but bitrise docs only say they 
have only macOS with simulator stack, that can't run on arm, can 
it?
Mar 19
parent Jacob Carlborg <doob me.com> writes:
On 2020-03-20 06:48, Kagamin wrote:
 You mean that CI compiles LDC and druntime right on iphone? I thought 
 CPU clock looks like arm, 
No, it compiles LDC and druntime/Phobos on macOS using cross-compiling. Cross-compiling is the official way you compile apps for iOS devices. You don't have permission to create a new process (fork) on iOS devices so a compiler running on iOS is not possible.
 but bitrise docs only say they have only macOS 
 with simulator stack, that can't run on arm, can it?
They support running on physical devices: "With Bitrise’s iOS device testing solution, you can run iOS tests on physical devices without having to set up and register your own devices" "Our device testing solution is based on Firebase Test Lab: it uses real, production devices running in a Google data center to test your app" https://devcenter.bitrise.io/testing/device-testing-for-ios/ -- /Jacob Carlborg
Mar 19
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2020-03-19 11:22, Petar Kirov [ZombineDev] wrote:

 A bit off-topic, but how does it compare to other services like Azure 
 Pipelines, GitHub Actions, BuildKite, etc. that support self-hosted 
 runners? (Also the first two have free macOS runners and Windows 
 runners.) From a quick look through the page they indeed offer many 
 features tailored to mobile dev,
The only reason I picked Bitrise is because it's the only CI service, that I could find at least, that offers testing on physical devices for free.
 but at least for work, I wouldn't 
 choose a CI solution that doesn't offer support for self-hosting runners.
In this case I would say it's an advantage to not have to deal with self-hosting runners. It's a PITA to automate testing on physical devices. For example, I have no idea how the CI service (if they do) reset the devices after a test. The only way I've been able to get an app on an device (without having to upload it somewhere) is through Xcode. The only way I've been able to run something on the device using the command line (which is required for automation) is to create an XCTest test (the testing framework used by Xcode). It's extremely unfriendly if you're not following the exact workflows that Apple have designed. Apple have proprietary protocols and private frameworks to deploy something to a device. -- /Jacob Carlborg
Mar 19