On 02.12.2024 15:44, Bart wrote:
On 02/12/2024 14:09, Tim Rentsch wrote:
Bart <bc@freeuk.com> writes:
On 30/11/2024 05:25, Tim Rentsch wrote:
EVERYBODY cares about compilation speeds. [...]
>
No, they don't. I accept that you care about compiler speed. What
most people care about is not speed but compilation times, and as
long as the times are small enough they don't worry about it.
>
Another difference may be relevant here. Based on other comments of
yours I have the impression that you frequently invoke compilations
interactively. A lot of people never do that (or do it only very
rarely). In a project I am working on now I do builds often,
including full builds where every .c file is recompiled. But all
the compilation times together are only a small fraction of the
total, because doing a build includes lots of other steps, including
running regression tests. Even if the total compilation time were
zero the build process wouldn't be appreciably shorter.
Yes, a compiler is no interactive tool. (Even if some, or Bart, use it
that way.) I've also mentioned that upthread already.
I want to add that there's also other factors in professional projects
that makes absolute compilation times not the primary issue. Usually
we organize our code in modules, components, subsystems, etc.
The 'make' (or similar tools) will work on small subsets, results will
(automatically) be part of a regression on unit-test level. Full builds
will require more time, but the results will be part of a higher-level
test (requiring yet more time).
It just makes little sense to only compile (a single file or a whole
project) if you don't at least test it.
But also if you omit the tests, the compile's results are typically
instantly available, since there's usually only few unit instances
compiled, where each is comparably small. In case one compiles mostly
monolithic software he gets worse response-characteristics, of course.
Multiple compiles for the same thing, as Bart seem to employ, makes
sense to fix compile-time (coding-)errors after a significant amount
of code has changed. That's where habits get relevant; Bart said that
he likes the (IMO costly) piecewise incremental fix/compile cycles[*],
I understand that this way to work (with 'make' or triggered by hand)
will lead to observable delays. Since Bart will likely not change his
habits (or his code organization) the speed of a single compilation
is relevant to him. - There's thus nothing we have left to discuss.
[*] Were I (for example) prefer to fix, if not all, at least a larger
set of errors in one go.
But it might be appreciably longer if the compilers you used were a lot
slower! Or needed to be invoked more. Then even you might start to care
about it.
You don't care because in your case it is not the bottleneck, and enough
work has been put into those compilers to ensure they are not even slower.
(I don't know why regression tests need to feature in every single build.)
Tests are optional, it doesn't need to be done "every time".
If all you want is to _sequentially_ process each single error in
a source file you don't need a test; all you need is to get the
error message, to start the editor, edit, and reiterate the compile
(to get the next error message, and so on). - Very time consuming.
But as soon as the errors are [all] fixed in a module... - what
do you do with it? - ...you should test that what you've changed
or implemented has been done correctly.
So edit/compile-iterating a single source is more time-consuming
than fixing it in, let's call it, "batch-mode". And once it's
error-free the compile times are negligible in the whole process.
I understand that you care about compiler speed, and that's fine
with me; more power to you. Why do you find it so hard to accept
that lots of other people have different views than you do, and
those people are not all stupid?
You might also accept that for many, compilation /is/ a bottleneck in
their work, or at least it introduces an annoying delay.
And there are various ways to address that.
Or are you suggesting that the scenario portrayed here:
https://xkcd.com/303/
is a complete fantasy?
It is a comic. - So, yes, it's fantasy. It's worth a scribbling
on a WC wall but not suited as a sensible base for discussions.
Do you really consider yourself
the only smart person in the room?
Perhaps the most impatient.
Don't count on that.
Janis