From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4570 invoked by alias); 23 Aug 2011 13:43:51 -0000 Received: (qmail 4556 invoked by uid 22791); 23 Aug 2011 13:43:49 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Aug 2011 13:43:24 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7NDhOCH014930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2011 09:43:24 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7NDhN7A002347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2011 09:43:24 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p7NDhNOj013075; Tue, 23 Aug 2011 15:43:23 +0200 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p7NDhMPH013074; Tue, 23 Aug 2011 15:43:22 +0200 Date: Tue, 23 Aug 2011 14:51:00 -0000 From: Jakub Jelinek To: Dimitrios Apostolou Cc: gcc-patches@gcc.gnu.org, Steven Bosscher , Alexandre Oliva Subject: Re: [var-tracking] small speed-ups Message-ID: <20110823134322.GF2687@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <20110822120533.GU2687@tyan-ft48-01.lab.bos.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg01891.txt.bz2 On Tue, Aug 23, 2011 at 02:40:56PM +0300, Dimitrios Apostolou wrote: > I was hoping you'd ask so I'll ask back :-) Why are we doing it that > way? Why so much indirection in the first place? Why create inline > functions just to typecast and why do we need this CONST_CAST2 > ugliness in C code. I bet there are things I don't understand so I'd > be happy to listen... It is not indirection, it is abstraction, which should make the code more readable and allow changing the implementation details. > OK I'll do that in the future. Should I also move some other htab > functions I saw in var-tracking and rtl? FOR_EACH_HTAB_ELEMENT comes > to mind, probably other too. I guess FOR_EACH_HTAB_ELEMENT could move too (together with all the support though - tree-flow.h and tree-flow-inline.h related stuff). > It's used only once, that's why I deleted the function. I'll bring > it back if you think it helps. Yes, please. > >> dst->vars = (shared_hash) pool_alloc (shared_hash_pool); > >> dst->vars->refcount = 1; > >> dst->vars->htab > >>- = htab_create (MAX (src1_elems, src2_elems), variable_htab_hash, > >>+ = htab_create (2 * MAX (src1_elems, src2_elems), variable_htab_hash, > >> variable_htab_eq, variable_htab_free); > > > >This looks wrong, 2 * max is definitely too much. > > For a hash table to fit N elements, it has to have at least 4/3*N > slots, or 2*N slots if htab has the 50% load factor I was proposing. For var-tracking, 50% load factor is IMHO a very bad idea, memory consumption of var-tracking is already high right now, we IMHO don't have the luxury to waste more RAM. > In total for dataflow_set_destroy I can see that calls to > attrs_list_clear() have been reduced from 500K to 250K, and I can > also see a reduction of free() calls from htab_delete(), from 30K to free calls? If you avoid free calls, then you end up with a memory leak. I can understand when you avoid pool_free calls... Jakub