On Mon, Mar 19, 2007 at 04:32:41PM +0100, Andre Poenitz wrote: > On Mon, Mar 19, 2007 at 11:56:51AM +0100, Enrico Forestieri wrote: > > On Mon, Mar 19, 2007 at 11:32:57AM +0100, Helge Hafting wrote: > > > > > Andre Poenitz wrote: > > > [...] > > > > Status quo: > > > > > > > > (plain g++) touch *.C ; time make: 38.5 s > > > > (ccache g++) touch *.C ; time make: 9.4 s > > > > wc -c *.o: 4.36 MB > > > > > > > Nice! > > > Such improvement makes it interesting to test lyx-svn more > > > often too. More time for trying all sorts of test patches, fixes > > > and experimental features. > > > > > > I hope nobody objects. Bigger files shouldn't be harder to > > > work with, and with such speedups. . . > > > > I am objecting. I only have 256 Mb of memory and right now I am barely > > able to successfully compile src/buffer.C. > > This objection is hard to take seriously. I try neverthless.
You're right. I am not a professional programmer, so what I say may very well be inaccurate. > A reality check seems to be in order. Compiling the combined > Graphics.C takes 140 MB with profile information, and so does > the former GraphicsConverter.C. buffer.C takes 145 MB btw. So > the size of the compiler process is fairly independent > of the actual line count of the file. > > And that sort of makes sense, actually. After all, a compilation > unit using a handful std includes usually ends up in the range > of 20-100 kLOC. > > The innocent errorlist.C of 32 lines is 21481 lines after the > preprocessor run. Buffer.C goes up from 1730 to 93380. So only a > marginal part (0.15% and 18%, respectively) of what the compiler sees > is actual LyX code. And, what wonder, the margin is bigger for bigger > files. buffer.C has a cost/value ratio 120(!) times as big as that of > errorlist.C _because_ it is fat. > > Sorry. Reality check failed. Completely. Thank you for assuring that I am wrong. However, I am aware that complexity is only marginally related to the source size. What I was not able to convey is that I fear that melting all sources together may lead to bigger memory requirements. > [I am surprised you are able to link LyX. After all, swapping during. > linking was the reason I bought my laptop with 512 MB to _link_ LyX, > not to compile it. Are you sure you measure what you think you do?] It is indeed the linking stage which is failing when I compile in debugging symbols. > > 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. > > 2300 lines and "large files"? Just run the gcc -E ... | wc for > real numbers. > > > No, I am not going to buy more memory (wouldn't fit in > > my laptop anyway) or a new computer in the near future. > > No problem. Declining changes based on fear, uncertainty and doubt > instead of using real numbers is what made the project as great as > it is. I beg your pardon but I am not sufficiently skilled to predict the amount of memory which is required to compile a given source, so, given this uncertainty, I can only fear/doubt that compilation may fail. > I certainly hit a mental barrier when I think of spending time > on LyX development taking time X as long as I know it could be done > in time X/2 (or X/60 for the case of null builds). The point is what is the X value. There's a big difference if X=2 days, or X=2 hours, or X=2 minutes (or X=0 in the case of no builds). Then I don't want certainly be the one who made you abandon LyX development, so I withdraw my objection. I can simply return to the user status in case I cannot compile LyX without 1Gb of memory. -- Enrico
