Re: __attribute__ ((cleanup) patch

[Pavel Simerda <psimerda redhat com>]

> From: "Colin Walters" <walters verbum org>
> On Fri, 2012-10-19 at 12:05 -0400, Pavel Simerda wrote:
> 
> > I, personally, was considering using some faster compiler for
> > development.
> > Pavel Tišnovský wrote an article about tcc and it might save me a
> > lot of
> > time waiting for compilation.
> 
> I doubt it, though it does depend on what kind of build you're doing.
> For developer incremental builds (i.e. you haven't touched the
> Makefiles, only modified .[ch] files),

Moving changes around, often. Rebasing, bisecting, testing if a multitude
of subsequent commits actually build.

> where you have a decently fast
> machine (circa 2010+ CPU and hard disk), and a warm cache from a
> recent
> build...you're talking about a ballpark possibility of going from 1.5
> seconds to 1.3 I'd guess.  Just not worth it.

Once I get down to 1.5 seconds, we can talk about it :D. I just realised
I'm *not* using ccache so let's see how much it helps.

> Also, from a quick inspection, tcc isn't going to speed up
> g-ir-compiler, unfortunately one of the slower parts of the build (my
> fault actually, but very hard to make faster).

That's another question, yes.

> And even if it's faster, how good is the DWARF generation?  Your
> build may be even 10 seconds faster, but if you have to rebuild it when you
> want to use GDB, that's not really a win.

I don't have enough information for that one.

> Anyways if you come back to me and tell me that building with tcc is
> useful for you, I bet I can gain back a substantial amount of the
> lost speed (or more) by e.g. switching to nonrecursive automake.

Could be of interest. Or maybe just making the recursion less aggressive. I am
going to do some configure.ac cleanups anyway as its current state is horrible.
But I wasn't going to do much with Makefile.am's.

Btw, I had to see myself, so I tested LLVM's support for __attribute__((cleanup))
with success.

Pavel