From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Add 'bytevector-slice'. Date: Sat, 14 Jan 2023 00:48:52 +0100 Message-ID: <871qnyatcr.fsf@gnu.org> References: <20230111150015.10219-1-ludo@gnu.org> <57a2d974-0278-409c-678a-6daf7672ba81@telenet.be> <87358eekkd.fsf@gnu.org> <1581c465-4c80-c24a-e526-0a63f99eb80e@telenet.be> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="715"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cc: guile-devel@gnu.org, Andy Wingo To: Maxime Devos Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sat Jan 14 00:49:27 2023 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pGTnb-000AUv-5X for guile-devel@m.gmane-mx.org; Sat, 14 Jan 2023 00:49:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGTnB-0003zY-Bj; Fri, 13 Jan 2023 18:49:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGTn7-0003zA-OQ for guile-devel@gnu.org; Fri, 13 Jan 2023 18:48:59 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGTn6-0004jP-21; Fri, 13 Jan 2023 18:48:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=9xlxUmdZUeK1JBidwWR0DLGv7u9RBTaImHOOEFuRlD8=; b=MvciOS9DZeoEiMmRa7w/ HVLnB2cn5EvRGT3jeTZrI/P82Xcts6StYZC2M9YFAvW1wTebA/EzqZzwMto7diI50Yp+w2XesO8lL mDA3LoSVaeHxTk70TJIrpmBPJ599UOiPZLfbglY9K3z3Serw71qWQb+d1RKCfVd6duQWnSSZzPdp4 m7gb5nL9LGyt24wCHxxzDYQnozR7Cqj8L+IaREYbcXfRLnt8Vwe7BM/HIEB0tMyHzJRouMyzaHE98 r6y3EV4ssSdU0jzexvkCZjKreaEyEhWIQIFK1DueGr4suYWNNheq3B4F9lojebKkLEFD6mZScSsaN AiLbwYZbg4AW4g==; Original-Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201] helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGTn5-0001Lm-AY; Fri, 13 Jan 2023 18:48:55 -0500 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Quintidi 25 =?utf-8?Q?Niv=C3=B4se?= an 231 de la =?utf-8?Q?R=C3=A9volution=2C?= jour du Chat X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu In-Reply-To: <1581c465-4c80-c24a-e526-0a63f99eb80e@telenet.be> (Maxime Devos's message of "Fri, 13 Jan 2023 12:56:13 +0100") X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:21577 Archived-At: Maxime Devos skribis: > On 13-01-2023 12:32, Ludovic Court=C3=A8s wrote: >>> IIUC, if you use bytevector-slice iteratively, say: >>> >>> (let loop ((bv some-initial-value) >>> (n large-number)) >>> (if (> n 0) >>> (loop (bytevector-slice bv 0 (bytevector-length bv)) >>> (- n 1)) >>> bv)) >>> >>> you will end up with a bytevector containing a reference to a >>> bytevector containing a reference to ... containing a reference to the >>> original reference, in a chain of length =E2=89=83 large-number. >> The =E2=80=98parent=E2=80=99 word is here just so the backing memory isn= =E2=80=99t reclaimed >> while the slice is still alive. >> Whether there=E2=80=99s a long chain of =E2=80=98parent=E2=80=99 links o= r not makes no >> difference to GC performance nor to memory usage. > > This is false, the opposite holds: memory usage is at least linear in > the length of the chain, because the objects in the chain are pairwise > non-eq?: for a chain (O_1, O_2, ..., O_n) that is alive, each object > O_i in the chain is kept alive (because that's what the 'parent' link > is for). Because bytevector-slice does a fresh allocation, there then > are n different objects. Hence, memory usage is at least > 'SCM_BYTEVECTOR_HEADER_SIZE * sizeof(scm_t_bits) * n'. Ah yes, that=E2=80=99s right, I misunderstood the comment. In the example above, where we=E2=80=99re only dealing with slices, we could =E2=80=9Cskip=E2=80=9D the parent (i.e., have each slice=E2=80=99s parent p= oint to the =E2=80=9Croot=E2=80=9D of the hierarchy), but I don=E2=80=99t think we can assume this to be the case generally. Ludo=E2=80=99.