Compilation speed #175
Comments
|
Just for kicks, even faster ... sub 4 seconds ... |
|
A couple of factors.
This is especially pronounced for the win32 build: |
|
/I suspect the CPU, as you do, but I suspect your storage is the real slowdown. Given the age of the hardware and the ready availability of components it's cheap to update the CPU and the storage relatively easily. Here's that fastest processor for that socket -- should fit, give a nice performance boost, about $29 USD (free shipping): https://www.ebay.com/sch/i.html?_from=R40&_trksid=p4432023.m570.l1313&_nkw=i7+3770&_sacat=0 Next up the storage - likely SATA, your primary drive likely is short on the available IOPS. About $58 USD for this 1TB , very speedy, SSD: If you want to really go fast, then a M.2 to PCIE adaptor will let you step up to the next level , ~$6 : And then select a M.2 drive, which can be had for $35 -- prices are recently falling dramatically. Networking -- I hope these will help. For a few dollars your performance will be greatly improved. I anticipate you may even be able to find better deals locally. |
|
Thank you for the suggestions. Those prices reflect on the US market. In Europe, prices did not really go down. I blame the pandemic and the Russo-Ukraine war. With an international purchase, I would need to pay import tax. By the way, the CPU you recommended would only give me a slight boost, according to userbenchmark.com. The time I would spend on the upgrade process would probably exceed the benefits. Also, more and more USB-ports on my system's main-board are failing. I will probably update some day anyways. ;) However, not everyone can do. While working on this project for the past years, I communicated with users from Africa and South America. They are stuck with 32bit systems, sometimes of the Pentium 4 era. They depend on projects like this since they cannot use the official WhatsApp Destkop client due to the limitations of their systems. I see no reason to make their life even harder by forcing a cache wipe into the build process. That was – if I remember correctly – the context I mentioned the long build times in. :) |
|
Might go even faster if you don't build to the intermediate obj/o files and go straight to dll/so by compiling all the c files at once (can get the benefit of not having to scan through all the header includes for multiple times, for each c file). Speeds up compile times by about x2 for some of the other pidgin plugins I worked on, hopefully gives a boost here too? |
|
On my system, recompiling the plug-in's go part takes 6 seconds on my system. Recompiling the entire C part takes 2 seconds. I have no intention to speed that up. In a previous contribution #166, Bryant opted to drop the build cache prior to building. This will make go re-download and re-compile all dependencies. That I deem unacceptable. On a side-note: I just noticed that when using CGO (go's ffi features which we have to use), the go build process is single-threaded. According to this thread, it seems to be by design. More cores will not help in this matter. |
|
The goal is within this thread only : Improve a developer's workflow, based on the metric of compilation speed. Specifically yours! I am not pulling any other threads in here. It's good to know about the 32-bit users in other countries. I would recommend then that we keep some kind of 32-bit compilation around to support these users. I was identifying key parts of your workflow that would speed up this compilation, and probably really improve anything else you do with the machine. I was citing costs because I wasn't necessarily expecting you to buy things, but perhaps the community could ? (these are relatively modest parts, some people might even have them around) Thoughts ? |
|
A quick note on multi-threading the compile, notice the speedup I applied in the second try "cmake --buld . -j4 " not because I thought it should be applied, but just because that was proof the ~7s could still be improved if necessary (and as expected with the right parallelization). That being said, on rereading your last comment -- believe I am reading that you are quoting the go downloading parts to your machine at approximately 1min 29s? ( other parts of the build about 7s total ? ). |
With the recent issue related to building, I was reminded of the time it took you to download and compile the required sources.
For kicks I wanted to see how far apart we were for compilation performance.
Timing the local compilation I am downloading and building in less than 7 seconds. You had mentioned it was taking "minutes" to do the same from a clean repo oull. What could possibly be taking so long on your side ?
reference 'dumb' compilation test:
The text was updated successfully, but these errors were encountered: