--- Comment #14 from bangerth at dealii dot org 2007-09-21 02:29 ---
We are now again on par with gcc 3.3 in terms of memory use (3.3 uses 298 MB
whereas 4.1 uses 280MB). This is a factor of 2 or 3 less than what we used
to use. We are also about a factor of 2 faster than in the 3.3 and
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-09-20 14:24
---
Still a frontend only issue. At -O2 we have
parser: 13.57 (85%) usr 0.62 (58%) sys 14.08 (83%) wall
536975 kB (90%) ggc
TOTAL : 15.91 1.0717.00
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-18
23:57 ---
This is still only a front-end issue:
parser: 14.19 (84%) usr 0.49 (51%) sys 14.64 (82%) wall
560492 kB (91%) ggc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-09
05:05 ---
Wow, compiling this on ia64-linux at -O2 gives:
parser: 50.14 (80%) usr 0.58 (49%) sys 50.75 (79%) wall
797327 kB (93%) ggc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25
01:40 ---
cp/parser.c:285 (cp_lexer_new_main) 0: 0.0%
22585856:63.1% 0: 0.0%
6332928:24.0% 5
tree.c:966 (build_constructor_from_list) 28488: 0.0% 0:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28
00:52 ---
On the mainline, (on x86) we use about 300 megs which is an improvement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614
--- Additional Comments From dmartin at cliftonlabs dot com 2005-01-27
13:43 ---
As a point of reference, it's using around 550M on x86. A 50% expansion on a 64
bit architecture (with more registers and opcodes) does not seem completely
unreasonable to me. So perhaps it's not a backend
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-27
13:24 ---
(In reply to comment #6)
> I checked out CVS head on 1/27/2005. The memory consumption on this file on
> x86_64 was "only" 750M. I don't know if this qualifies as excessive or not so
> I'll let someone els
--- Additional Comments From dmartin at cliftonlabs dot com 2005-01-27
13:04 ---
I checked out CVS head on 1/27/2005. The memory consumption on this file on
x86_64 was "only" 750M. I don't know if this qualifies as excessive or not so
I'll let someone else close it.
--
Wha
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-25
06:45 ---
This explains a lot:
vtables = 917; vtable searches = 0
vtable entries = 0; vtable elems = 82020
(In reply to comment #4)
> We could create one ADDR_EXPR for the pure virtual case which will both speed
> up
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-25
04:26 ---
All of the memory seems to becoming from virtual functions, some from pure
virtual functions (which
we could optimizate a little better).
/* You can't call an abstract virtual function; it's abst
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-25
00:07 ---
cp/class.c:7224 (build_vtbl_initializer)6525792: 2.6% 0:
0.0% 22705120:17.7% 0:
0.0% 913466
cp/class.c:7600 (add_vcall_offset) 9266784: 3.7% 0:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24
21:07 ---
For me on the mainline on powerpc-darwin this takes a max of 500MB, at -O0 and
-O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614
--- Additional Comments From dmartin at cliftonlabs dot com 2005-01-24
21:00 ---
Created an attachment (id=8056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8056&action=view)
A file requiring 1.4G of virtual memory to process on g++ 3.4.3
--
http://gcc.gnu.org/bugzilla/show_
14 matches
Mail list logo
