Hey, I'm Uria, a math student at Tel-Aviv University. I'm conducting a poll regarding problems that software developers or scientists might have when using Linux. There are only five questions in this poll and it shouldn't take you more than five minutes to answer. So, if you're a software developer or a scientist, It'll be very helpful if you could spend some time and answer it.
Here's the link: https://www.surveymonkey.com/s/66X526C

Also, if you have any comments or insights related to these questions, I urge you to share them with me here.

Thanks, Uria.

Surprisingly small number of questions. I'm curious what you hope to conclude from the aggregated answers.

It seems like you might be expecting an interesting relationship between which Linux distro one is using and whether/why you are dissatisfied with the build speed of your own project. I would not expect to find any correlation found to deliver any useful insight; meaning I doubt there is a problem cause correlation (this Linux distribution does significantly more to slow down your build than that distribution); and I doubt any solution market insight (that someone proposing a solution can significantly reduce complexity or effort by focusing on only the distributions that matter). That leaves only useless correlation: those whose software development projects are very big tend to select (my guess would be Centos) more often than those with smaller projects, but so what.

I'm using Centos and very very dissatisfied with (my project) build speed. The root root cause is that corporate management doesn't understand the importance of build speed. I don't know how one might poll for cause of slow build, but it is the lack of any such attempt that I found strangest in that survey.

In my specific (anecdote not data) situation, that root root cause translates into two root causes:
1) Source code structure: Lack of formal build performance cleanup projects for the source code leads to excess inclusion of .hpp files: cpp A includes hpp X for good reason and hpp X includes hpp Y for what seems locally to be a good reason. But cpp A instantiates nothing (directly or indirectly) from hpp Y, so the inclusion of hpp Y in cpp A is pure waste of build time. Multiply by thousands of cpp files each wastefully including thousands of hpp files and you have a mess.
2) Lack of IT and/or build-engineering support.
2a) Thousands of cpp files are being compiled, typically by one developer who is waiting for that result, while other developers are debugging or editing or involved in non technical overheads (of being in a big organization). Meanwhile the group has many shared machines (accessible over GB LAN) that are sitting idle. For any individual developer to "reinvent the wheel" of distributing builds over multiple machines (that he lacks full authority over anyway) is at any moment too big a detour from his assigned job. So if management never assigns IT or build-engineering resources to set up the basic mechanism for distributed builds, they never happen (each build occurs on one machine, while the rest are idle).
2b) When the same thousands of small hpp files are read thousands of times each on machines with Gigabytes of spare ram, there is far more ram than needed for all those files to stay in cache and never be read from disk more than once per build. But in the Windows build, corporate IT mandates nasty anti-malware systems that rescans everything every time it is touched in a way that wrecks most of the benefits of caching. Meanwhile in the Linux build all those hpp files are in an nfs mount, which is either mis-configured (or maybe nfs is lame) such that most of the performance benefits of local caching are destroyed by nfs checking to see whether the original file change in the middle of the build. That IT problem is beyond the ability of developers to fix (the product we develop is not networking nor file system nor specific to Linux, so it is outside our expertise) and IT issues are barely addressed when management understands it matters and certainly not when management doesn't understand.

You said

Could you please elaborate?
What are some of the problems you are experiencing? How is it affecting your project?

I really thought I did elaborate (the whole rest of the post).

The effect on the project:

Most of the code I need to maintain is in hpp files. That is not due to the source code structure issue I mentioned, but due to our correctly doing almost all work in templated classes.

So most of the enhancements I make to the project involve edits to hpp files.

Each small amount of editing is followed by waiting a long time for a build, because many of the changes need to be tested before making the next change, but also because heavily templated C++ code makes it hard to debug some compile time failures when you have made more than a few changes since the last build (sometimes I need to build just to sort out compile time issues and don't even need to test).

All that adds up to more time spent waiting for builds than on doing the real work.

BTW, are you making the survey results public? It showed me results as of when I took the survey, but not very much because I seem to have been second. Most online surveys let those who took the survey check back later and see newer results. This one seems not to.

Johnsfine

I'd like to contact you in private. How do I do this?