From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: Proposal: block-based vector allocator Date: Thu, 08 Dec 2011 20:48:28 +0400 Message-ID: <4EE0EA5C.1090505@yandex.ru> References: <4EDDA68B.5050601@yandex.ru> <4EDE315E.3030804@yandex.ru> <4EDEF421.6090800@yandex.ru> <4EDF8F8E.8050401@yandex.ru> <87hb1b25i7.fsf@uwakimon.sk.tsukuba.ac.jp> <4EE03FFD.1090400@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1323362917 7359 80.91.229.12 (8 Dec 2011 16:48:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 8 Dec 2011 16:48:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 08 17:48:33 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RYh96-0005Uk-15 for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2011 17:48:32 +0100 Original-Received: from localhost ([::1]:37803 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYh95-0004i4-IE for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2011 11:48:31 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYh92-0004ho-7n for emacs-devel@gnu.org; Thu, 08 Dec 2011 11:48:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RYh91-0001di-7P for emacs-devel@gnu.org; Thu, 08 Dec 2011 11:48:28 -0500 Original-Received: from mail.dev.rtsoft.ru ([213.79.90.226]:54841) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RYh90-0001cO-QO for emacs-devel@gnu.org; Thu, 08 Dec 2011 11:48:27 -0500 Original-Received: (qmail 29323 invoked from network); 8 Dec 2011 16:48:23 -0000 Original-Received: from unknown (HELO ?192.168.5.146?) (192.168.1.70) by 0 with SMTP; 8 Dec 2011 16:48:23 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 213.79.90.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:146582 Archived-At: On 12/08/2011 06:10 PM, Stefan Monnier wrote: > Someone could try to change the allocator so those blocks are exactly > 1-page in size and get allocated via mmap: I did this even before I started with block-based vector allocator. > - using mmap will ensure that we factor out malloc from the equation. > - using page-size (presumably 4KB) blocks rather than the current 16KB Current sizes are 1K except string data, which is 8K. > Then re-run some problematic case (e.g. the million-lines compile buffer) > to see if this helps. It really should help, tho I don't hold much hope > that it will make a significant difference (e.g. more than 30% > difference would be significant). My favorite byte-force-recompile benchmark usually consumes ~89M. With my vector allocator it shrinks to 78M. When mmap() is enabled, it shrinks to 76M. Not too much. But for (definitely pathological) compile buffer case, results are very unexpected (I tried with 100000-lines buffer). Fresh instance is 18M. With compile buffer, it grows to 142M and shrinks to 141M after killing *compilation* and garbage-collect. When mmap() is enabled, it grows to 138M and shrinks back to 21M (twenty one) after kill & GC. Dmitry