Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Fri, 14 Jun 2024 19:24:04 +0100
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <v4i1s4$30goi$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me>
 <v49seg$14cva$1@raubtier-asyl.eternal-september.org>
 <v49t6f$14i1o$1@dont-email.me>
 <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
 <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me>
 <v4c8s4$1lki1$4@dont-email.me> <20240613002933.000075c5@yahoo.com>
 <v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com>
 <v4hs0f$2ve92$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Jun 2024 20:24:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3cbeaf55936e5f695a7fb47506a986f6";
	logging-data="3162898"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/wizdGZWVsmW9CERCQyTWZ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:BKTpiKgz3GC1iZBp8uPNA17IY8A=
Content-Language: en-GB
In-Reply-To: <v4hs0f$2ve92$1@dont-email.me>
Bytes: 4992

On 14/06/2024 17:43, David Brown wrote:
> On 13/06/2024 16:43, Michael S wrote:

>> Somewhat more than a second on less modern hardware. Enough for me to
>> feel that compilation is not instant.
>> But 1 MB is just an arbitrary number. For 20 MB everybody would feel
>> the difference. And for 50 MB few people would not want it to be much
>> faster.
>>
> 
> But what would be the point of trying to embed such files in the first 
> place?  There are much better ways of packing large files.

I remember complaining that some tool installations were bloated at 
100MB, 500MB, 1000MB or beyond, and your attitude was So what, since 
there is now almost unlimited storage.

But now of course, it's Why would someone ever want to do X with such a 
large file! Suddenly large files are undesirable when it suits you.

>  You can 
> always increase sizes for things until you get problems or annoying 
> slowdowns, but that does not mean that will happen in practical situations.
> 
> And even if you /did/ want to embed a 20 MB file, and even if that took 
> 20 seconds, so what?  Unless you have a masochistic build setup, such as 
> refusing to use "make" or insisting that everything goes in one C file 
> that is re-compiled all the time, that 20 second compile is a one-off 
> time cost on the rare occasion when you change the big binary file.
> 
> Now, I am quite happy to agree that faster is better, all other things 
> being equal.  And convenience and simplicity is better.  Once the 
> compilers I use support #embed, if I need to embed a file and I don't 
> need anything more than an array initialisation, I'll use #embed.  Until 
> then, 5 seconds writing an "xxd -i" line in a makefile and a 20 second 
> compile (if it took that long) beats 5 minutes writing a Python script 
> to generate string literals even if the compile is now 2 seconds.

That's a really bad attitude. It partly explains why such things as 
#embed take so long to get added.

I've heard lots of horror stories elsewhere about projects taking 
minutes, tens of minutes or even hours to build.

How much of that is due to attitudes like yours? You've managed to find 
ways of working around speed problems, by throwing hardware resources at 
it (fast processors, loads of memory, multiple cores, SSD, RAM-disk), or 
using ingenuity in *avoiding* having to compile stuff as much as 
possible. Or maybe the programs you build aren't that big.

But that is not how you fix such problems. Potential bottlenecks should 
be identified and investigated.

/Could/ it be faster? /Could/ it use less memory? /Could/ a simple 
language extension help out?

I can understand you having little interest in it because you just use 
the tools that available and can't do much about it, but it should be 
somebody's job to keep on top of this stuff.

 >  Until
 > then, 5 seconds writing an "xxd -i" line in a makefile and a 20 second
 > compile (if it took that long) beats 5 minutes writing a Python script
 > to generate string literals even if the compile is now 2 seconds.

So now you need 'xxd'. And 'Python'. And 'make'. When it could all be 
done effortlessly, more easily and 100 times faster within the language 
without all that mucking about.

 > Unless you have a masochistic build setup, such as
 > refusing to use "make" or insisting that everything goes in one C file
 > that is re-compiled all the time,

When you write such tools, you don't know what people are going to do 
with them, how much they will push their limits. And you can't really 
dictate how they develop or build their software.