On 23 Dec 1999, Lars Gullik Bjønnes wrote:

> Allan Rae <[EMAIL PROTECTED]> writes:
> 
> | Actually for me it's LyXAction that seems to be the "Compile Killer" but
> | then maybe I've just left the room for a cup of tea by the time lyxfunc
> | arrives on the scene.
> 
> I thought that my recent changes to LyXAction reduced the compile
> times quite a bit.

They did I just hadn't noticed.

Here's a couple of very interesting numbers for you recorded on a dual
552MHz bp6 (yes it's 400MHz celerys running at 92MHz FSB),  I've included
LyXAction because it used to be really slow but now is quite fast.
All times in seconds, times in () are at 400MHz.  Sorted in decreasing
order of time when compiled with SGI's stl implementation.  gcc-2.95.1
column is the times for just using the stl implementation that comes
standard with that distro.  The LyX codebase is a snapshot from Christmas
Eve. Just used "make" not "make -j2" or anything else fancy other than
CXX="time g++"

                gcc-2.95.1      SGI's STL 3.2
lyxfunc.C       24.04           328.23  (452.04)
lyx_cb.C        10.11           217.03  (291.35)
buffer.C        16.61           174.36  (240.33)
Bullet.C         1.00           155.33  (215.94)
lyxfont.C        3.61            98.80  (135.78)
lyxrc.C          5.45            31.38   (43.17)
paragraph.C      7.46            30.23   (41.41)
filetools.C      2.72            24.39   (33.68)
lyx_main.C       4.31            23.99   (33.28)
filedlg.C        4.27            23.91   (33.17)
LaTeX.C          5.37            23.22   (31.97)
figinset.C       5.86            21.23   (30.31)
LyXAction       11.26            12.49   (17.06)

That's the main group of files that take longer than 30 seconds to compile
at 400MHz.  As you can guess there is a huge cluster of files below
this.  I've just tried to list the main files that take forever ;-) when
compiled with SGI's stl.

BTW, this isn't meant as showing off how much faster I can compile than
anyone else its to show the HUGE difference in compilation times when
using SGI's stl.  In particular you'll notice that Bullet.C takes 155
times longer to compile when using SGI's stl!!!  This is all due to the
static string arrays kept there.  I'm sure I originally implemented it as
const char*[] since its static and internal and constant.  There is no
need for fancy memory management at runtime and hence no need for using
std::string here.  I'm sure we've had this arguement before but I'll plow
on regardless:  Can someone give me a good reason why we should keep using
string for the static const arrays?

Allan. (ARRae)

P.S. I didn't believe the Bullet.C times either so recompiled that file
several times and all SGI stl times were within 0.5 seconds of the 155
figure.

P.P.S. If I was really thorough I would repeat the tests using lyxstring
instead of SGI's string implemenation for the SGI stl case.  But I'm too
lazy.  Besides I've been pretending to be a kernel hacker for the last few
days trying to get Linux working with the latest Abit bp6 bios release --
which Abit has officially removed from its FTP site earlier today and
announced with deep regret to be a pile of sh!t.

Reply via email to