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: immediate strings Date: Thu, 24 May 2012 03:14:44 -0400 Message-ID: References: <4FBB51E7.6080601@yandex.ru> <4FBDD04F.9010203@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1337843704 28969 80.91.229.3 (24 May 2012 07:15:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 24 May 2012 07:15:04 +0000 (UTC) Cc: Dmitry Antipov , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 24 09:15:03 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 1SXSGA-0004k1-S5 for ged-emacs-devel@m.gmane.org; Thu, 24 May 2012 09:14:58 +0200 Original-Received: from localhost ([::1]:40004 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXSGA-0003UJ-2t for ged-emacs-devel@m.gmane.org; Thu, 24 May 2012 03:14:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXSG5-0003U4-Fh for emacs-devel@gnu.org; Thu, 24 May 2012 03:14:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXSG0-0005F0-LN for emacs-devel@gnu.org; Thu, 24 May 2012 03:14:53 -0400 Original-Received: from ironport-out.teksavvy.com ([206.248.143.162]:16041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXSG0-0005EE-Hi for emacs-devel@gnu.org; Thu, 24 May 2012 03:14:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09MCpYd/2dsb2JhbABEDrQDgQiCFQEBBAFWFgoDBQsLNAERFBgNJIgcBboJixuFKQOjM4FYgjBVgTo X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="182165116" Original-Received: from 76-10-150-29.dsl.teksavvy.com (HELO pastel.home) ([76.10.150.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 24 May 2012 03:14:46 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id AC67F58C01; Thu, 24 May 2012 03:14:44 -0400 (EDT) In-Reply-To: <4FBDD04F.9010203@cs.ucla.edu> (Paul Eggert's message of "Wed, 23 May 2012 23:08:15 -0700") 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.143.162 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:150631 Archived-At: > That might work. But this raises another idea: assuming most tiny strings > don't have text properties, won't it improve performance overall if > any string with text properties is forced to be an ordinary string, so > that immediate strings can reuse the rarely-used 'intervals' member > for data? That's part of the reason why I'm interested in his statistics about which strings have text properties. But even if there's a potential gain here, there's still the issue that we may then have to convert an immediate string into an ordinary string when text-properties are added, which will imply basically relocating the string data, with the usual risk that we might happen to do that right in the middle of a loop keeping a pointer to the inside of the string's data. > Another thought that comes to mind, is that we could leave > the mark bit where it is (the most significant bit of 'size'), > and reserve 'size' values >= (EMACS_INT / 2 & ~0xffff) No need to be that careful: the `size' field has 2 free bits (since the size is limited by what integer can fit in a Lisp_Object), and only 1 is used (for the markbit), so we could just grab a second bit from `size' for the `immbit'. Stefan