This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/10944] alloc_page in ggc-page.c is slow
- From: "steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Oct 2003 14:37:14 -0000
- Subject: [Bug other/10944] alloc_page in ggc-page.c is slow
- References: <20030522192332.10944.pinskia@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10944
steven at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2003-06-01 18:58:30 |2003-10-13 14:37:14
date| |
------- Additional Comments From steven at gcc dot gnu dot org 2003-10-13 14:37 -------
The new patch implements suggestion 1 from last nights list.
Andrew, you identified the loop over free_pages as a time consumer, but now that
it is gone, I get virtually no measurable time improvements (10ths of seconds on
>1min total compilation time) for the test case for PR8361. Which (not
surprisingly) once again shows that GC is slow because with each call
ggc_collect we need to do more and more marking...
Are you absolutely, positively sure that this loop is a performance hog?
Perhaps you can try the patch, it bootstrappes (c,objc,c++) and showed no
regressions on i686. So far I haven't found convincing evidence that it
improves performance significantly except for the most pathological (artificial)
cases.
Sigh, back to waiting for a new GC strategy...