On Mon, Mar 19, 2007 at 06:20:54PM +0100, Enrico Forestieri wrote: > > 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 think I can reassure you that increasing the file size from, say, 100 lines, to, say 10000 lines (to use some extreme values) won't change your ability to compile LyX on any machine. Either it works now, then so it will then, or it doesn't work in both cases. > > [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. The linker memory usage is _the_ problem (and also the reason why linking LyX takes as long as it does). There was an ugly hack in the 2.95 era using objcopy that was useful in fooling the linker to be much less demanding but I am not sure this still works with modern lds. I can try to dig it out again and try to come up with numbers. > > 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. It won't. > > 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). In the original mail I gave my numbers for the src/graphics subdirectory: 38 seconds. Given that this constitutes 12 out of 466 .C files (plus a few in boost) I'd put X = ~1500 s = 25 min. My personal value for the null build is between 14 and 22 seconds (probably depending on on some kernel side caching). Reducing that by a factor of either 2 or 60 would be great. Of course, linking is worse (~1:15 here), but even reducing _only_ the null build time by a factor of 2 would reduce the roundtrip time by 7-11s on top of ~75s, i.e. by 10%-14%. That's not exactly neglegible. > 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. As I said, your ability to compile LyX won't be affected by lumping a few files together. Andre'
