From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: PURESIZE increased (again) Date: Thu, 27 Apr 2006 17:53:40 -0500 (CDT) Message-ID: <200604272253.k3RMreIx001541@jane.dms.auburn.edu> References: <87lku5u6tx.fsf@pacem.orebokech.com> <200604272212.k3RMCe4C001158@jane.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1146178606 28749 80.91.229.2 (27 Apr 2006 22:56:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 27 Apr 2006 22:56:46 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 28 00:56:46 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FZFPg-0004WR-GP for ged-emacs-devel@m.gmane.org; Fri, 28 Apr 2006 00:56:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZFPg-0003TV-0n for ged-emacs-devel@m.gmane.org; Thu, 27 Apr 2006 18:56:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FZFOp-00039m-J9 for emacs-devel@gnu.org; Thu, 27 Apr 2006 18:55:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FZFOn-00038E-7L for emacs-devel@gnu.org; Thu, 27 Apr 2006 18:55:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZFOn-00038A-33 for emacs-devel@gnu.org; Thu, 27 Apr 2006 18:55:49 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FZFQQ-0006Um-Gn; Thu, 27 Apr 2006 18:57:30 -0400 Original-Received: from jane.dms.auburn.edu (jane.dms.auburn.edu [131.204.53.201]) by manatee.dms.auburn.edu (8.13.6/8.13.6) with ESMTP id k3RMsNcK018366; Thu, 27 Apr 2006 17:54:23 -0500 (CDT) Original-Received: from jane.dms.auburn.edu (localhost [127.0.0.1]) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3) with ESMTP id k3RMrftW001544; Thu, 27 Apr 2006 17:53:41 -0500 (CDT) Original-Received: (from teirllm@localhost) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3/Submit) id k3RMreIx001541; Thu, 27 Apr 2006 17:53:40 -0500 (CDT) X-Authentication-Warning: jane.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: raeburn@gnu.org In-reply-to: (message from Ken Raeburn on Thu, 27 Apr 2006 18:29:31 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:53528 Archived-At: I may be wrong. I got the impression that differences in, for instance, the C library and even the actual version of, say glibc, did matter, from, for instance, the following comment from alloc.c, which seems to say that different versions of glibc waste different amounts of memory on alignment. But maybe I misunderstood the comment. /* Padding to leave at the end of a malloc'd block. This is to give malloc a chance to minimize the amount of memory wasted to alignment. It should be tuned to the particular malloc library used. On glibc-2.3.2, malloc never tries to align, so a padding of 0 is best. posix_memalign on the other hand would ideally prefer a value of 4 because otherwise, there's 1020 bytes wasted between each ablocks. In Emacs, testing shows that those 1020 can most of the time be efficiently used by malloc to place other objects, so a value of 0 can still preferable unless you have a lot of aligned blocks and virtually nothing else. */ #define BLOCK_PADDING 0