public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Matz <matz@suse.de>
To: Mike Stump <mrs@apple.com>
Cc: Marco Morandini <morandini@aero.polimi.it>, <gcc@gcc.gnu.org>,
	<gcc-patches@gcc.gnu.org>
Subject: Re: PATCH: Re: A user question (was: Re: Faster compilation speed)
Date: Wed, 14 Aug 2002 04:10:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.33.0208141301070.13269-100000@wotan.suse.de> (raw)
In-Reply-To: <B66700BC-AF19-11D6-96AC-000393941EE6@apple.com>

Hi,

On Tue, 13 Aug 2002, Mike Stump wrote:

> :-(  The biggest single culprit count wise is some aggressive checking
> code.  The below change save 1.5 minutes of compile time out of 5
> minutes on an n=20,000 case.  The top of the tree is much worse than a
> gcc 3.1 compiler, 5 minutes compared to 56 seconds.

This is a typical case why I strongly dislike such arbitrary cutoff means
to avoid slow behaviour instead of redesigning how it works.  From the
code you posted it seems, that the blocks bitmap is extremely sparse (in
the second loop only one bit is set in evry case, the second loop only
seems to set one bit each time by pure luck), but still it's completely
traversed, through pointer chasing even (the bb double linked list).
This suggests to change the interface of count_or_remove_death_notes() to
take a bitmap (not sbitmap), and rearrange the outer loop of it, to use
EXECUTE_IF_SET_IN_BITMAP().


Ciao,
Michael.

  parent reply	other threads:[~2002-08-14  4:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-13 10:34 Marco Morandini
2002-08-13 10:47 ` Marco Morandini
2002-08-13 14:29 ` Mike Stump
2002-08-13 17:06   ` PATCH: " Mike Stump
2002-08-13 19:53     ` Richard Henderson
2002-08-14  4:10     ` Michael Matz [this message]
2002-08-14  4:42       ` Michael Matz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.33.0208141301070.13269-100000@wotan.suse.de \
    --to=matz@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=morandini@aero.polimi.it \
    --cc=mrs@apple.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).