On Jun 10, 2005, at 5:24 PM, Rob Bearman wrote:
I've been building with exactly the configuration specified in the
README.MacOSX file. I thought at one time I needed
--disable-concept-checks,
but it turns out I've been mistakenly leaving off the 's' at the end
for
some time (which I guess means the bogus flag was ignored). I just
built
clean without it - after rerunning ./configure - to verify. I'm
building on
Tiger, but before 4/29 I'd been building on 10.3 without seeing major
issues.
I do see the increase in processor use that you report - both on the
Mac and
on Windows, increasing as the document grows but only if I hammer away
at
the keyboard. Normal typing doesn't hit that hard on the processor and
even
hammering doesn't give me delays. I don't know why we're seeing a
difference, but I have the same results on three machines (Powerbook,
Mini,
G5).
Rob kindly provided me with his config.log and the lyx application he
compiled to see what the differences were.
His version does run much faster on my machine than mine does, though
fast typing still pegs processor usage at the maximum and there is a
*slight* delay before text appears on the screen. Why the difference?
From what I can tell, it comes down to this. Rob is using Mac OS X 10.4
(=Darwin 8.0.0), whereas I use 10.3.9 (= Darwin 7.9.0). Part of the
difference is that his version of gcc 3.3 is labeled "Apple Computer,
Inc. build 1809", whereas mine is labeled "Apple Computer, Inc. build
1671". I can't find any documentation on the differences, either by
googling or searching Apple's developer site. However, one effect of
the difference is that, whereas I need to set
"--disable-concept-checks" to get lyx to configure for me (or it
complains about ostream, istream, etc. being present but not usable),
Rob does not. So at least one bug in Apple's version of gcc-3.3 has
been fixed.
Nonetheless, producing a time profile of Rob's version of lyx shows
pretty much what mine shows: way too much time is being spent in
lengthcombo.C (about 65% of total time). So merely switching to a newer
version of gcc doesn't solve the underlying problem.
Bennett
