This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: switch statement performance
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Paul Vixie <paul at vix dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: 20 Jan 2004 14:13:33 -0800
- Subject: Re: switch statement performance
- References: <20040120021909.76B0614BBE@sa.vix.com>
Paul Vixie <paul@vix.com> writes:
> today i wanted to go on a performance-related witch hunt, so i added:
>
> --------
>
> --- stmt.c.orig Mon Jan 19 19:39:41 2004
> +++ stmt.c Mon Jan 19 19:57:25 2004
> @@ -5393,6 +5393,12 @@
> || (TREE_CODE (index_expr) == COMPOUND_EXPR
> && TREE_CODE (TREE_OPERAND (index_expr, 1)) == INTEGER_CST))
> {
> + /* If the sequence would be absurdly long and slow, send warning. */
> + if (extra_warnings
> + && count >= case_values_threshold ()
> + && compare_tree_int (range, 10 * count) > 0)
> + warning ("large range, slow code");
> +
> index = expand_expr (index_expr, NULL_RTX, VOIDmode, 0);
>
> /* If the index is a short or char that we do not have
>
> --------
>
> and then ran -W against bind8, bind9, the freebsd kernel, and other smaller
> things. the results weren't amazing or stupendous, but they were quite
> useful. one of the things i learned is that a lot of sparse switch stmts
> should be left as they are for cleanliness reasons, since they are not
> inside loops or otherwise called often enough to warrant rewriting them to
> avoid the if-else code generation behaviour signalled by the above warning().
You didn't explain why you wanted to do this, or what problem you're
trying to solve; I feel like this is the last message of a long
discussion. Are you concerned about the object code quality, or the
quality of the C code that GCC is compiling?
--
- Geoffrey Keating <geoffk@geoffk.org>