From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Quesition about Lisp_Vector Date: Sat, 12 Nov 2011 10:49:45 +0200 Message-ID: <83mxc1g1xy.fsf@gnu.org> References: <553A1AC5-4002-4175-AD1F-CC596356E44C@raeburn.org> <87ty6aj9al.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1321087931 10830 80.91.229.12 (12 Nov 2011 08:52:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Nov 2011 08:52:11 +0000 (UTC) Cc: raeburn@raeburn.org, qguo@ualberta.ca, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 12 09:52:03 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 1RP9Jj-0006ui-Al for ged-emacs-devel@m.gmane.org; Sat, 12 Nov 2011 09:52:03 +0100 Original-Received: from localhost ([::1]:38162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RP9Ji-0003qh-Ux for ged-emacs-devel@m.gmane.org; Sat, 12 Nov 2011 03:52:02 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RP9Jd-0003qR-CF for emacs-devel@gnu.org; Sat, 12 Nov 2011 03:52:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RP9JY-0007hz-Vz for emacs-devel@gnu.org; Sat, 12 Nov 2011 03:51:57 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:49275) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RP9JY-0007hp-Mq for emacs-devel@gnu.org; Sat, 12 Nov 2011 03:51:52 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LUJ00800HMYZE00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 12 Nov 2011 10:51:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.66.14]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUJ00856HY4THA0@a-mtaout23.012.net.il>; Sat, 12 Nov 2011 10:51:42 +0200 (IST) In-reply-to: <87ty6aj9al.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.175 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:146002 Archived-At: > From: "Stephen J. Turnbull" > Date: Sat, 12 Nov 2011 12:42:42 +0900 > Cc: Qiang Guo , emacs-devel@gnu.org > > Aside to OP: In Emacs Lisp although strings (ie, arrays with bytes as > elements and a non-uniform indexing scheme) are vectors in the API, > they don't share an implementation with general vectors. In fact the > string storage is allocated separately (another optimization, because > strings with len(data) % pointersize != 0 would waste substantial > amounts of memory, at least by 1980 standards), so there's always a > pointer indirection. This usually is not too inefficient since many > operations on strings are of the form "get string data, do O(len) > operation on it", so the overhead of a pointer dereference to "get > string data" is tolerable. Having string data accessible through indirection allows to relocate strings without affecting callers who have references to Lisp strings in local variables. (This is similar to the ability to relocate buffer text, because buffer text is also accessed through indirection.) These abilities are important, because strings, like buffers, can be large, so being able to relocate them during GC helps making more efficient use of the available memory.