From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-35294-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 31096 invoked by alias); 12 May 2003 22:16:02 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 30824 invoked by uid 71); 12 May 2003 22:16:00 -0000
Date: Mon, 12 May 2003 22:16:00 -0000
Message-ID: <20030512221600.30818.qmail@sources.redhat.com>
To: rth@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Zoltan Hidvegi <hzoli@hzoli.2y.net>
Subject: Re: c/10675: Compile time increases quadratically with struct size
Reply-To: Zoltan Hidvegi <hzoli@hzoli.2y.net>
X-SW-Source: 2003-05/txt/msg01382.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR c/10675; it has been noted by GNATS.

From: Zoltan Hidvegi <hzoli@hzoli.2y.net>
To: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, 
 hzoli@hzoli.2y.net, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c/10675: Compile time increases quadratically with struct size
Date: Mon, 12 May 2003 17:06:29 -0500 (CDT)

 --ELM1052777189-18480-0_
 Content-Transfer-Encoding: 7bit
 Content-Type: text/plain; charset=US-ASCII
 
 > Synopsis: Compile time increases quadratically with struct size
 > 
 > State-Changed-From-To: analyzed->closed
 > State-Changed-By: rth
 > State-Changed-When: Mon May 12 03:32:46 2003
 > State-Changed-Why:
 >     http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00989.html
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10675
 
 I've applied the patch to the gcc-3.3 and manually fixed the
 conflicts.  This does indeed fix the compile-time with gcc, but g++
 still behaves quadratically.  Also for C++ you may want to run the
 attached biggen3.sh, that will generate a struct as before, but it
 adds a constructor that zero-initializes all members.  This also have
 unusually large, although linear memory usage, e.g., the compile of a
 struct with 25000 members with constructor initializers needs 55M
 (based on the memory use showed by top on both AIX and Linux).  And
 even C still seems to have slow lookups, as if the hash is only used
 to detect duplicates, but for member lookup it still uses linear
 search.  Run the attached biggen5.sh to test this, it will create a C
 struct and a function that initializes the struct.  Because of all
 this, I'd like to reopen this bug, or should I open a new bug?
 
 Zoli
 
 --ELM1052777189-18480-0_
 Content-Transfer-Encoding: 7bit
 Content-Type: text/plain
 Content-Disposition: attachment; filename=biggen3.sh
 Content-Description: 
 
 #! /bin/sh
 let i=0
 echo 'struct foo {'
 while [ "$i" -lt "$1" ]
 do
     echo "    int i_$((i=i+1));"
 done
 echo "    int junk;"
 let i=0
 echo '    foo() :'
 while [ "$i" -lt "$1" ]
 do
     let 'i=i+1'
     echo "	i_$i(0),"
 done
 echo "	junk(0) {}"
 echo '};'
 echo 'struct foo f;'
 
 --ELM1052777189-18480-0_
 Content-Transfer-Encoding: 7bit
 Content-Type: text/plain
 Content-Disposition: attachment; filename=biggen5.sh
 Content-Description: 
 
 #! /bin/sh
 let i=0
 echo 'struct foo {'
 while [ "$i" -lt "$1" ]
 do
     echo "    int i_$((i=i+1));"
 done
 echo '};'
 #echo 'struct foo f;'
 
 let i=0
 echo 'void init_foo(struct foo *p) {'
 while [ "$i" -lt "$1" ]
 do
     echo "    p->i_$((i=i+1)) = 0;"
 done
 echo '}'
 
 --ELM1052777189-18480-0_--