From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2383 invoked by alias); 17 Jan 2012 16:48:38 -0000 Received: (qmail 2374 invoked by uid 22791); 17 Jan 2012 16:48:37 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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, 17 Jan 2012 16:48:19 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0HGmIN3032409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 11:48:18 -0500 Received: from host2.jankratochvil.net (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0HGmEMY011462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Jan 2012 11:48:16 -0500 Date: Tue, 17 Jan 2012 16:54:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: Sergio Durigan Junior , gdb-patches@sourceware.org Subject: Re: [RFC 1/8] Language independent bits Message-ID: <20120117164813.GA5344@host2.jankratochvil.net> References: <20120115203420.GA18901@host2.jankratochvil.net> 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 gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00604.txt.bz2 On Tue, 17 Jan 2012 17:34:03 +0100, Doug Evans wrote: > On Sun, Jan 15, 2012 at 12:34 PM, Jan Kratochvil wrote: > Sure, but I think this is excessively nitpicky. I agree with the part this was code moving, not new fields. > Each element is (at least) 16 bytes in size and gdb has been using > ints just fine so far. Evaluating each memory size carefully whether it can or can not exceed 2GB is too much burden on the human. Any such evaluation mistake then can mean deployment failure like which happened to Red Hat customer(s). I do not find the performance impact 4 -> 8 bytes measurable nowadays to justify such optimization cost. It is and it will be already a lot of work to fix all the existing wrong memory sizes as `int', trying to optimize them all properly for 4 vs. 8 bytes I do not find realistic. It may make sense only in some special cases like struct partial_symbol or struct main_type. Thanks, Jan