Comments on: How scalable is SCons?

By: Top posts for September 2010 « blog.melski.net

Top posts for September 2010 « blog.melski.net — Thu, 30 Sep 2010 15:07:01 +0000

[...] How scalable is SCons?: 6% of page views [...]

By: gavenkoa

gavenkoa — Thu, 02 Sep 2010 11:54:46 +0000

> How about GNU Make scalable?

Wow! I found your second article, that answer question:

http://blog.electric-cloud.com/2010/07/21/a-second-look-at-scons-performance/

By: gavenkoa

gavenkoa — Thu, 02 Sep 2010 11:46:46 +0000

How about GNU Make scalable?

If it equal to sh?

By: Popular, Fast, or Usable: Pick One at Software Carpentry

Popular, Fast, or Usable: Pick One at Software Carpentry — Wed, 21 Jul 2010 15:59:25 +0000

[...] not when you look at its performance, or rather, lack of performance. According to Eric Melski’s numbers, SCons’s runtime seems to grow as the square of the number of things being built, which is [...]

By: rotinom

rotinom — Wed, 26 May 2010 17:53:37 +0000

Just ran across this, and not sure if anyone can benefit, but I have deployed SCons in a large environment, with good luck. I don’t have a file count, but the SLOC count was >1 million lines of C, Fortran, C++, and a smattering of “other”, and over 100 individual SConscript files.

Prior to SCons, we had developers using makefiles, and everything was single-threaded. Processes were not in place to ensure that the makefiles would work multi-threaded, it it was a very organic project, with 15-20 years of development effort.

SCons was put in place over a small period of time, and the automatic dependency analysis, and -j functionality reduced our build times by an order of magnitude, and ensured that the project was correct every single time.

So, call us a success. We had a great deal of “correctness” issues, as well as built speed issues, and SCons solved both. Granted, they could probably get faster, but the ease of implementation, and general flexibility and extensibility were incredible.

The biggest complaint, is on a project of that size, you have about a minute from when you type ‘scons’ to when it starts building something. If you are just working on getting a single file built (say, working through syntax issues), it can be tedious to do, but you can just copy & paste the command line, and side-step the build system at least.

By: Eric Melski

Eric Melski — Thu, 06 May 2010 17:15:09 +0000

@Mikhail: obviously a shell script is not a substitute for a full-featured build system. I never said it was. However, I think it is important to determine what portion of the total build time comes from the actual work of the build (compiles, links, etc), versus what portion comes from the build system itself. I can’t think of a better way to measure that than by comparing the SCons time to the shell script time. Do you have an alternative suggestion, or are you saying that you think this metric is completely irrelevant?

I do hope to put up a similar article based around make. In fact, I’ve already collected the data for that article. The problem is that blogging is not my primary responsibility at Electric Cloud, so unfortunately I don’t get as much time to work on it as I would like.

Thanks for your comments!

By: Mikhail

Mikhail — Thu, 06 May 2010 14:45:40 +0000

The results of this exercise look impressive and obviously not in favor of Scons. At the same time the comparison to the results of the shell script running the same commands in the same order as the Scons-based build has a limited value to anyone except probably the Scons developers. If you are so smart as to write a shell script that does exactly what is needed to build your project then you don’t need any build system whatsoever, Scons included. Probably in some situations this degenerate special case (building from scratch or full build) is important enough to warrant a special script/rule/whatever in your build system but you have to take a burden of maintaining consistency between incremental/full builds then.

What would be much more interesting and useful is to compare to some real build system i.e. Make. Plus any other use cases besides build from scratch would be extremely useful. Supposedly you performed this experiment using scripts of some sort, then it should not be too hard to adapt them for Make as well. Without that it looks just like Scons bashing.

By: czrpb

czrpb — Wed, 05 May 2010 01:31:18 +0000

@walt: That is true: In a sufficiently strict environment — such as for security, legal or export reasons — you can imagine that such traceability is *required* in the end-2-end solution.

@Eric: Thanks!! We have worked hard to achieve this. I wish I could talk more, especially technically. My comments here should not be taken to mean I am unimpressed with some of EC’s tech! (I meant mostly to address the particular use case run against scons! wink!)

Thanks everyone for allowing me to participate!

By: Eric Melski

Eric Melski — Tue, 04 May 2010 21:46:55 +0000

@czrpb: That must create some interesting challenges with respect to managing the build artifacts. I also wonder how many developers you have on your project, and what build tool you’re using that you have such confidence in the incremental build features.

In any case, I think you and your team are the exception, rather than the norm. Bravo on setting up such a robust build system. Thanks for your comments!

By: walt

walt — Tue, 04 May 2010 20:32:29 +0000

@czpb: You must have a really well designed build setup to have that level of trust in it.

I guess more likely you know exactly what changed and what needs to rebuild based on that.

In our case we won’t always recompile everything either, but that’s mostly in the case where an application .c file changed (rather than an include or a library file) or if it’s just a shell or Perl script that changed.