From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Proposal: block-based vector allocator Date: Fri, 01 Jun 2012 13:43:53 -0400 Message-ID: References: <4EDDA68B.5050601@yandex.ru> <4FB4AFA4.7020601@yandex.ru> <4FBA32D9.5090704@yandex.ru> <4FC775B5.30904@yandex.ru> <4FC8709C.6000903@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1338572653 8404 80.91.229.3 (1 Jun 2012 17:44:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Jun 2012 17:44:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 01 19:44:10 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SaVtJ-0007M9-KI for ged-emacs-devel@m.gmane.org; Fri, 01 Jun 2012 19:44:01 +0200 Original-Received: from localhost ([::1]:50162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaVtJ-0001Bz-6v for ged-emacs-devel@m.gmane.org; Fri, 01 Jun 2012 13:44:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaVtF-0001B1-D5 for emacs-devel@gnu.org; Fri, 01 Jun 2012 13:43:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SaVtD-0006h0-Oc for emacs-devel@gnu.org; Fri, 01 Jun 2012 13:43:56 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:33277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SaVtD-0006gq-KL for emacs-devel@gnu.org; Fri, 01 Jun 2012 13:43:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu0/O+L9q/2dsb2JhbABEtBGBCIIVAQEEAScvIwULCw4mEhQYDSSIHAW6CZBEA6MzgViDBQ X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="186062868" Original-Received: from 206-248-191-106.dsl.teksavvy.com (HELO pastel.home) ([206.248.191.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 01 Jun 2012 13:43:54 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id D4D6458CDD; Fri, 1 Jun 2012 13:43:53 -0400 (EDT) In-Reply-To: <4FC8709C.6000903@yandex.ru> (Dmitry Antipov's message of "Fri, 01 Jun 2012 11:34:52 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:150718 Archived-At: > I don't understand this. Any block-allocated vector P0 has the size > less than or equal to VECTOR_BLOCK_BYTES. So, mem_find (P0) will > always return mem_node M0 where M0->end - M0->start == > VECTOR_BLOCK_BYTES (IOW, such a mem_node always corresponds to > a vector block). If P1's size is greater than VECTOR_BLOCK_BYTES, > including the case when it's equal to sizeof (vector_block), mem_find > (P1) will always return it's own corresponding node M1 where P1 is > equal to M1->start and M1->end - M1->start is never equal to > VECTOR_BLOCK_BYTES. BTW, if we change the vector allocation so it only uses vector-blocks for vectors smaller than "vector-block-size / 2", as I think we should, then I think your reasoning breaks down. Stefan