On Mon, Mar 19, 2007 at 12:33:14PM +0100, Helge Hafting wrote:

> Enrico Forestieri wrote:
> > I am objecting. I only have 256 Mb of memory and right now I am barely
> > able to successfully compile src/buffer.C. Moreover, I cannot anymore
> > compile with debugging symbols because I get out of memory errors, and
> > have to selectively compile single files with -g.
> > I think that with such large files I will not be able to compile LyX.
> > No, I am not going to buy more memory (wouldn't fit in my laptop anyway)
> > or a new computer in the near future.
> >   
> Good point.
> There are many files much smaller than buffer.C's 44kB though.
> Perhaps a "don't merge beyond 32kB" policy might help you?

I don't think that size and number of lines monotonically map to
memory requirements as there are files bigger than buffer.C requiring
less resources to be compiled.

> Also consider using a swap file when compiling. That should
> replace the out of memory problems with disk waiting.

The swap is already used when needed, and indeed buffer.C takes forever
to be compiled. So, using the swap is defeating the original purpose
of faster compilations for me. Indeed, these proposal could even increase
the required time. Right now, compiling from scratch takes almost 2 hours
on cygwin and I remember that I was able to compile 1.3.x in about 45
minutes. Compiling with scons is a bit faster but not that much as it
takes about 1 hour and 40 minutes. I think that the difference is to be
attributed to autotools and the fact that a fork() is quite expensive
as it has to be emulated with native Windows calls. Anyway, this is not
a cygwin problem, as the required times for compilation are not much
different on Solaris 10 with a Sun-Blade-1000 with 512 Mb of memory.
Indeed, they are quite the same as with cygwin/scons (the Sun machine
is now 5 years old and features an ultrasparc III at 750 MHz).
As a side note, compilation on Linux with a similar powerful processor
as the Sun machine is much faster. This means that compilation speed
is depending on the architecture and a solution which is good for a given
system may not be good for another one.

-- 
Enrico

Reply via email to