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 12:50:27 +0400 Message-ID: <4EE07A53.3060204@yandex.ru> References: <4EDDA68B.5050601@yandex.ru> <4EDE315E.3030804@yandex.ru> <4EDEF421.6090800@yandex.ru> <4EDF8F8E.8050401@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 1323334236 28029 80.91.229.12 (8 Dec 2011 08:50:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 8 Dec 2011 08:50:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 08 09:50:29 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 1RYZgT-0007Di-9R for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2011 09:50:29 +0100 Original-Received: from localhost ([::1]:52455 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYZgS-0000G5-Mg for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2011 03:50:28 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:32896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYZgQ-0000Fy-Bg for emacs-devel@gnu.org; Thu, 08 Dec 2011 03:50:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RYZgP-0006BI-95 for emacs-devel@gnu.org; Thu, 08 Dec 2011 03:50:26 -0500 Original-Received: from mail.dev.rtsoft.ru ([213.79.90.226]:37043) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RYZgO-0006B4-Py for emacs-devel@gnu.org; Thu, 08 Dec 2011 03:50:25 -0500 Original-Received: (qmail 30716 invoked from network); 8 Dec 2011 08:50:22 -0000 Original-Received: from unknown (HELO ?192.168.5.146?) (192.168.1.70) by 0 with SMTP; 8 Dec 2011 08:50:22 -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:146574 Archived-At: On 12/07/2011 08:30 PM, Stefan Monnier wrote: > I'm not convinced your result is because your code does better than > malloc. Instead I expect it's because it avoids the mem_node overhead. > Recompiling and trying again without conservative stack scanning should > factor out this effect. Without conservative stack scanning, it works at least not worse (I believe we should ignore the differences less than, say, 0.5%). But, as I have said, there are further improvements possible. > You can't do compaction without changing the Lisp_Vector's layout > (adding an indirection, as is done for Lisp_Strings). I know, and I'm just saying that my proposal contains nothing which makes compaction impossible or too tricky. > I thought we agreed that GC performance is not a concern here. > Of course, every change to the layout can impact the performance of the > GC. Have you measured the impact of your code on GC performance? Not yet. But will do it, of course. Dmitry