[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: slow makefiles are getting even slower

From: Zdenek Kabelac
Subject: Re: slow makefiles are getting even slower
Date: Thu, 15 Aug 2002 11:59:10 +0200
User-agent: Mutt/1.4i

On Wed, Aug 14, 2002 at 05:56:26PM -0600, Tom Tromey wrote:
> >>>>> "Zdenek" == Zdenek Kabelac <address@hidden> writes:
> Zdenek> Am I the only one who is noticing constant slowdown of
> Zdenek> processing
> Do you mean running automake or running make?

Well as I've said - checkout the speed of  'automake' generartion
for avifile project - libtoolize,aclocal, autoheader, autoconf
are slow as well - but automake beats them all as it's as slow
as all of them together.

I don't think I'm doing some bad - also I'm trying to keep it
compatible across many version of auto* tools so it's not
using the latest extensions of automake.

> Zdenek> it's really getting crazy - 9MB just for Makefiles...
> That is a bit absurd, though of course it depends on the layout and
> complexity of your project.

the size of after

with (left column - uptodate Debian Unstable):
autoconf (GNU Autoconf) 2.53
automake (GNU automake) 1.6.3
libtoolize (GNU libtool) 1.4.2a

right column - old Debian Potato: (which is also noticable faster)
Autoconf version 2.13
automake (GNU automake) 1.4
libtoolize (GNU libtool) 1.3.3

make maintainer-clean    - ~ 9835KB        8401KB               - ~11865KB        9237KB
configure                - ~16356KB       10689KB

so - ok it's not 9 byt almost 6.5MB but it's still unreal - the project
has 10MB of sources and auto* staff will take just over 65% just 
for Makefiles to be able to compile project - there is really something
wrong within whole auto* architecture.

> I'd say that we care, but we just haven't prioritized it very highly.

Well I guess you all have PIV 2.5GHz boxes - but I could assure
you that auto* tools are becoming unusable on 400MHz Celerons even with 256MB
of memory - it takes ages to regenerate configure and Makefiles.

> My perception is that the complaints we see are about not having a
> smooth upgrade path, followed by feature requests.  I haven't tried to
> actually measure that perception against reality.  Also there are

Well you really should try it - it's really becoming a monster - and
when you take into account how much slower the gcc is becoming (especialy
for compilation of C++ projects) I'm starting to think that
Linux has been infiltrated with M$ people - as I have access to
many various intallations I could compare the project compilation
speed on various setups - and while  400MHz with old Potato and gcc-2.95.2
is just fine -  the current auto* and gcc3.2 is just something unreal
and after all they both have to produce the same exectable...

> always complaints about the complexity of the system, which are
> justified but hard to derive patches from.

I've proposed several times few things which would certainly 
drasticaly improve the speed - though they are for different
parts of auto* tools project - there were some reactions - but
so far non of them were realized and there is not visible any 
progress here (and as I've said before the whole auto* stuff is getting
constanly slower and more space consuming - not mentining the
problems with backward compatibility).

  .''`.    Zdenek Kabelac  address@hidden,,}
 : :' :          Debian GNU/Linux maintainer - www.debian.{org,cz}
 `. `'  Modern processors are the most advanced heating systems around.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]