table dist that I use at work currently ships with
>> | $ g++ --version | g++ (GCC) 4.0.2 20050917 (prerelease) (Debian
>> 4.0.1-8)
>> |
>> | I notice that LyX link times have become painfully slow (10+ |
>> minutes) compared to 2+ minutes last time I tested on this box
t; | $ g++ --version
| > | g++ (GCC) 4.0.2 20050917 (prerelease) (Debian 4.0.1-8)
| > |
| > | I notice that LyX link times have become painfully slow (10+
| > | minutes) compared to 2+ minutes last time I tested on this box
| > | with gcc 3.x. Does anybody else see this? Lars?
| >
| &
ebian 4.0.1-8)
> |
> | I notice that LyX link times have become painfully slow (10+
> | minutes) compared to 2+ minutes last time I tested on this box
> | with gcc 3.x. Does anybody else see this? Lars?
>
> Compiling with debug on? I never do that and get ~10 sec links...
Yes, defa
Angus Leeming <[EMAIL PROTECTED]> writes:
| Since I'm whining about things being slow...
|
| The Debian unstable dist that I use at work currently ships with
| $ g++ --version
| g++ (GCC) 4.0.2 20050917 (prerelease) (Debian 4.0.1-8)
|
| I notice that LyX link times have become pai
; g++ (GCC) 4.0.2 20050917 (prerelease) (Debian 4.0.1-8)
>
> I notice that LyX link times have become painfully slow (10+ minutes)
> compared to 2+ minutes last time I tested on this box with gcc 3.x.
> Does anybody else see this? Lars?
>
> --
> Angus
>
>
Since I'm whining about things being slow...
The Debian unstable dist that I use at work currently ships with
$ g++ --version
g++ (GCC) 4.0.2 20050917 (prerelease) (Debian 4.0.1-8)
I notice that LyX link times have become painfully slow (10+ minutes)
compared to 2+ minutes last time I test
On Fri, Oct 10, 2003 at 08:51:53AM +, Angus Leeming wrote:
> Lars Gullik Bjønnes wrote:
>
> > Angus Leeming <[EMAIL PROTECTED]> writes:
> >
> > | Is this the solution to the long link times we have?
> > | http://article.gmane.org/gmane.comp.lib.boost.deve
André (and any others interested in speeding up link times at the
expense of a doubling in disk usage),
The attached script works for me. I have set its executable bit and
placed it in my path, using it as
$ make CXX=my_g++
Please check that make invokes g++ as
g++ ... -MT file.lo -MD
thingy std::<<
std::string::literal("Hello, world")
boost::closing::brace >
It furthermore increases compile and link times by a factor of four
while eating 8 GB of RAM for linking "Hello world"...
Andre'
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Oct 10, 2003 at 04:35:30PM +0200, Lars Gullik Bjønnes wrote:
>> | That does not prevent certain people to use 3.6 already...
>>
>> 3.6? Time-machine?
>
| Well, _you_ are the person who knows where to dig out this kind of
| stuff..
I thought you
On Fri, Oct 10, 2003 at 04:35:30PM +0200, Lars Gullik Bjønnes wrote:
> | That does not prevent certain people to use 3.6 already...
>
> 3.6? Time-machine?
Well, _you_ are the person who knows where to dig out this kind of
stuff..
Andre'
--
Those who desire to give up Freedom in order to gain S
On Fri, Oct 10, 2003 at 04:20:10PM +0200, Andre Poenitz wrote:
> That does not prevent certain people to use 3.6 already...
And what is 3.6 exactly ? What's in it ? :)
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Oct 10, 2003 at 03:47:34PM +0200, Christian Ridderström wrote:
>> On Fri, 10 Oct 2003, Christian Ridderström wrote:
>>
>> > So 'PCH' might be useful after all then... unfortunately I don't have 3.4,
>> > or I'd see how much time that saves. (My
On Fri, Oct 10, 2003 at 03:47:34PM +0200, Christian Ridderström wrote:
> On Fri, 10 Oct 2003, Christian Ridderström wrote:
>
> > So 'PCH' might be useful after all then... unfortunately I don't have 3.4,
> > or I'd see how much time that saves. (My experience with Borland was
> > that it reduced
On Fri, 10 Oct 2003, Christian Ridderström wrote:
> So 'PCH' might be useful after all then... unfortunately I don't have 3.4,
> or I'd see how much time that saves. (My experience with Borland was
> that it reduced compilation times tremendously, but produced HUGE
> 'cache'-files).
Oh, 3.4 i
On Fri, 10 Oct 2003, John Levon wrote:
>
> GCC 3.4 does.
>
> I didn't try lyx, but it knocked about 15-20% off total compile time for
> oprofile. And lyx has far worse header problems.
>
> For best support we'd want a "alllyx.h" which includes all the headers
> and to PCH that. Even without, -in
On Fri, Oct 10, 2003 at 12:28:12PM +0200, Andre Poenitz wrote:
> That's a compiler feature, and gcc does not support this (yet) AFAIK, so
> what exactly do you propose?
GCC 3.4 does.
I didn't try lyx, but it knocked about 15-20% off total compile time for
oprofile. And lyx has far worse header p
t.
> >
> > Hard to believe. That would be have the size we currently have...
>
> Read the original post. The guy was knocking his link times down to 1%
> of those he was experiencing without this. Presumably the linker must
> be doing some work in the other 99% of the
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Oct 10, 2003 at 01:08:37PM +0200, Lars Gullik Bjønnes wrote:
>> | Which is no good advice if the debug information is needed.
>>
>> OTOH linking is almost instantaneous if you compile without '-g'
>> Another part of the advice would be "compile
nal post. The guy was knocking his link times down to 1%
of those he was experiencing without this. Presumably the linker must
be doing some work in the other 99% of the time, with associated
memory use.
--
Angus
On Fri, Oct 10, 2003 at 01:08:37PM +0200, Lars Gullik Bjønnes wrote:
> | Which is no good advice if the debug information is needed.
>
> OTOH linking is almost instantaneous if you compile without '-g'
> Another part of the advice would be "compile only needed parts with
> -g"
So where's the --wi
On Fri, Oct 10, 2003 at 11:59:33AM +, Angus Leeming wrote:
> Angus Leeming wrote:
> > 88M to link xforms, 11M to link qt.
> That is 111M to link qt.
Hard to believe. That would be have the size we currently have...
Andre'
--
Those who desire to give up Freedom in order to gain Security, wil
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Oct 10, 2003 at 12:39:36PM +0200, Lars Gullik Bjønnes wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>>
>> | essentially double the space they did.
>> | $ ls -l lyx-xforms lyx-qt
>> | -rwxrwxr-x1 angusangus136152780 Oct 10 1
Angus Leeming wrote:
> 88M to link xforms, 11M to link qt.
That is 111M to link qt.
--
Angus
Andre Poenitz wrote:
> On Fri, Oct 10, 2003 at 11:32:52AM +, Angus Leeming wrote:
>> On Friday 10 October 2003 10:24 am, Andre Poenitz wrote:
>> > On Fri, Oct 10, 2003 at 11:15:45AM +, Angus Leeming wrote:
>> > > So, it knocks 1m20 of the link times for the
On Fri, Oct 10, 2003 at 12:39:36PM +0200, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
>
> | essentially double the space they did.
> | $ ls -l lyx-xforms lyx-qt
> | -rwxrwxr-x1 angusangus136152780 Oct 10 11:27 lyx-xforms
> | -rwxrwxr-x1 angusangus
Lars Gullik Bjønnes wrote:
> Can you do one round where you also run "strip --strip-debug" on the
> *.o files?
As I understand it the objcopy route does not strip debug info. Rather
it does not merge repeated strings. If I wanted to build an
executable without debug info, I'd do that from scratc
On Fri, Oct 10, 2003 at 11:32:52AM +, Angus Leeming wrote:
> On Friday 10 October 2003 10:24 am, Andre Poenitz wrote:
> > On Fri, Oct 10, 2003 at 11:15:45AM +, Angus Leeming wrote:
> > > So, it knocks 1m20 of the link times for the two executables at the
> > >
-f `find . -name '*.la'`
> $ time make
>
> real1m53.305s
> user0m15.510s
> sys 0m7.300s
>
> Kncking a further 1min off link times. Without any of this
> strangeness:
> real4m20.096s
> user3m29.100s
> sys 0m6.730s
The ratio real:user ha
Angus Leeming <[EMAIL PROTECTED]> writes:
| essentially double the space they did.
| $ ls -l lyx-xforms lyx-qt
| -rwxrwxr-x1 angusangus136152780 Oct 10 11:27 lyx-xforms
| -rwxrwxr-x1 angusangus180187449 Oct 10 11:27 lyx-qt
>
| size data remains essentially unchanged.
| $ s
On Friday 10 October 2003 10:24 am, Andre Poenitz wrote:
> On Fri, Oct 10, 2003 at 11:15:45AM +, Angus Leeming wrote:
> > So, it knocks 1m20 of the link times for the two executables at the
> > expense of 20% greater disk usage. size stats are unchanged.
>
> What are
On Fri, 10 Oct 2003, Andre Poenitz wrote:
> On Fri, Oct 10, 2003 at 12:23:08PM +0200, Christian Ridderström wrote:
> > Speaking about compilation times... long ago Borland's C++ compiler had
> > something they called 'precompiled header-files' (or something like that),
> > where the sort of had
300s
Kncking a further 1min off link times. Without any of this
strangeness:
real4m20.096s
user3m29.100s
sys 0m6.730s
Of course, you pay in disk usage, the executables taking up
essentially double the space they did.
$ ls -l lyx-xforms lyx-qt
-rwxrwxr-x1 angusangus136152780 O
On Fri, Oct 10, 2003 at 12:23:08PM +0200, Christian Ridderström wrote:
> Speaking about compilation times... long ago Borland's C++ compiler had
> something they called 'precompiled header-files' (or something like that),
> where the sort of had a cache of parsed header files. Is this something
bjdump.sh
>
> real0m17.685s
>
> Now regenerate the executables
> $ time make
> real3m5.312s
>
> So, it knocks 1m20 of the link times for the two executables at the
> expense of 20% greater disk usage. size stats are unchanged.
So the net gain is 1 minute, i.e
On Fri, Oct 10, 2003 at 11:15:45AM +, Angus Leeming wrote:
> So, it knocks 1m20 of the link times for the two executables at the
> expense of 20% greater disk usage. size stats are unchanged.
What are the RSS values during linking?
We can currently link (again) in 256 MB RAM and I&#x
Angus Leeming <[EMAIL PROTECTED]> writes:
| So, it knocks 1m20 of the link times for the two executables at the
| expense of 20% greater disk usage. size stats are unchanged.
>
| #! /bin/sh
| test $# -gt 0 || exit
| while (true); do
| objcopy --set-section-flags .debug_str=conte
.debug_str=contents,debug $file done
>
> Angus> and report back on subsequent link times/code size. Would you
> Angus> be interested or should I just drop it?
>
> This looks like a good idea...
All object files up to date, compiled with CXXFLAGS='-g -O -W -Wall'.
N
>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I could write a little script
Angus> find build/src -name '*.o' | while read file; do objcopy
Angus> --set-section-flags .debug_str=contents,debug $file done
Angus> and repo
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Is this the solution to the long link times we have?
> | http://article.gmane.org/gmane.comp.lib.boost.devel/26446
>
> Spell it out, don't force us to go hunting.
Shrug. The info is there
Angus Leeming <[EMAIL PROTECTED]> writes:
| Is this the solution to the long link times we have?
| http://article.gmane.org/gmane.comp.lib.boost.devel/26446
Spell it out, don't force us to go hunting.
(And I followed the thread on boost, and am absolutely not sure.)
--
Lgb
Is this the solution to the long link times we have?
http://article.gmane.org/gmane.comp.lib.boost.devel/26446
In the next couple of articles in the thread, it appears that they're
going to do this in the boost builds, so I guess it must be a
reasonable thing to do.
http://article.gman
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Sep 04, 2003 at 02:43:12PM +0200, Lars Gullik Bjønnes wrote:
>> Kuba Ober <[EMAIL PROTECTED]> writes:
>>
>> | On czwartek 04 wrzesieñ 2003 09:25 am, Angus Leeming wrote:
>> >> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt)
On Thu, Sep 04, 2003 at 02:43:12PM +0200, Lars Gullik Bjønnes wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
>
> | On czwartek 04 wrzesieñ 2003 09:25 am, Angus Leeming wrote:
> >> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt). This
> >> is making it somewhat painful to code
On czwartek 04 wrzesień 2003 09:46 am, Lars Gullik Bjønnes wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> | On czwartek 04 wrzesień 2003 08:43 am, Lars Gullik Bjønnes wrote:
> >> Kuba Ober <[EMAIL PROTECTED]> writes:
> >> | On czwartek 04 wrzesieñ 2003 09:25 am, Angus Leeming wrote:
> >> >> On
Kuba Ober <[EMAIL PROTECTED]> writes:
| On czwartek 04 wrzesieŠ2003 08:43 am, Lars Gullik Bjønnes wrote:
>> Kuba Ober <[EMAIL PROTECTED]> writes:
>> | On czwartek 04 wrzesieñ 2003 09:25 am, Angus Leeming wrote:
>> >> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt).
>> >>
On czwartek 04 wrzesień 2003 08:43 am, Lars Gullik Bjønnes wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> | On czwartek 04 wrzesieñ 2003 09:25 am, Angus Leeming wrote:
> >> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt).
> >> This is making it somewhat painful to code :-( C
Kuba Ober <[EMAIL PROTECTED]> writes:
| On czwartek 04 wrzesieñ 2003 09:25 am, Angus Leeming wrote:
>> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt). This
>> is making it somewhat painful to code :-( Could we think about revisiting
>> partial linking et al.?
>
| Unfortunate
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, Sep 04, 2003 at 08:39:40AM -0400, Kuba Ober wrote:
>
>> I guess it may be worthwhile to look at linker code, try profiling and see
>> where it spends most of its time :)
>
| One big thing is the debug info, and iirc gcc cvs reduces it rather
| cons
On Thu, Sep 04, 2003 at 08:39:40AM -0400, Kuba Ober wrote:
> I guess it may be worthwhile to look at linker code, try profiling and see
> where it spends most of its time :)
One big thing is the debug info, and iirc gcc cvs reduces it rather
considerably by discarding unused debug entries ...
j
On czwartek 04 wrzesień 2003 09:25 am, Angus Leeming wrote:
> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt). This
> is making it somewhat painful to code :-( Could we think about revisiting
> partial linking et al.?
Unfortunately, after looking at it again, it seems that at
Angus Leeming wrote:
> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt).
> This is making it somewhat painful to code :-( Could we think about
> revisiting partial linking et al.?
I suggest you use -O2 and --disable-debug for testing...
Regards, Alfredo
Angus Leeming <[EMAIL PROTECTED]> writes:
| On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt). This
| is making it somewhat painful to code :-( Could we think about revisiting
| partial linking et al.?
Last time I did this partial linking (as opposed to linking with the
obje
On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt). This
is making it somewhat painful to code :-( Could we think about revisiting
partial linking et al.?
--
Angus
54 matches
Mail list logo
