From bil at ccrma.Stanford.EDU  Wed Apr 19 11:32:51 2023
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Wed, 19 Apr 2023 11:32:51 -0700
Subject: [CM] Snd 23.3
Message-ID: <e682f64d8b67229e07b9447a119ba129@ccrma.stanford.edu>

Snd 23.3

s7: autoload bugfix

checked: sbcl 2.3.3

Thanks!: john M693, Todd Ingalls



From iainduncanlists at gmail.com  Sat Apr 29 07:30:56 2023
From: iainduncanlists at gmail.com (Iain Duncan)
Date: Sat, 29 Apr 2023 07:30:56 -0700
Subject: [CM] Protecting Scheme data structures from GC?
Message-ID: <CAN9NcLw+nphdALBeScBXDCdgqNdMvWWRm9Ge_yTWjQvvQEZJXg@mail.gmail.com>

Hi all, perhaps this is not possible, but I'm wanting to know how one might
prevent the GC from running over a Scheme let environment. The idea is that
it would be nice in my large sequencing environments to be able to have the
equivalent of static objects, where I know all the data members are meant
to stick around for the duration of a piece, but where I would also like to
speed up GC runs. (maybe I'm off base and this wouldn't speed up GC runs
anyway though...)

Any suggestions welcome!
iain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20230429/70ab77cf/attachment.html>

From bil at ccrma.Stanford.EDU  Sat Apr 29 10:13:58 2023
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Sat, 29 Apr 2023 10:13:58 -0700
Subject: [CM] =?utf-8?q?Protecting_Scheme_data_structures_from_GC=3F?=
In-Reply-To: <CAN9NcLw+nphdALBeScBXDCdgqNdMvWWRm9Ge_yTWjQvvQEZJXg@mail.gmail.com>
References: <CAN9NcLw+nphdALBeScBXDCdgqNdMvWWRm9Ge_yTWjQvvQEZJXg@mail.gmail.com>
Message-ID: <fe12f9fa334b82cd9e80cb511de25139@ccrma.stanford.edu>

To keep an environment from the being garbage collected,
assign it to a global variable -- as long as the variable
holds the environment, it will be safe.  This won't speed
up the GC.  It's possible to make s7 strings that are not
seen at all by the GC (make_permament_string), but it's much
trickier for an environment -- you'd have to be sure that
every cell of every variable in the environment was
permanent; otherwise the cell might have no one else
referring to it, and the GC would free it.



From iainduncanlists at gmail.com  Sun Apr 30 08:53:35 2023
From: iainduncanlists at gmail.com (Iain Duncan)
Date: Sun, 30 Apr 2023 08:53:35 -0700
Subject: [CM] Protecting Scheme data structures from GC?
In-Reply-To: <fe12f9fa334b82cd9e80cb511de25139@ccrma.stanford.edu>
References: <CAN9NcLw+nphdALBeScBXDCdgqNdMvWWRm9Ge_yTWjQvvQEZJXg@mail.gmail.com>
	<fe12f9fa334b82cd9e80cb511de25139@ccrma.stanford.edu>
Message-ID: <CAN9NcLxte6HbZYFt1uL0=kHGT3wQPGw7jyL=du6SpL0HxTmEDw@mail.gmail.com>

Thanks Bill. I guess I was hoping reducing how much it had to scan over
would make a scan faster, but am not correct. Do you have any suggestions
for what one can do to cut GC times down on a code level when there is a
lot of code going?

thanks
iain


On Sat, Apr 29, 2023 at 10:14?AM <bil at ccrma.stanford.edu> wrote:

> To keep an environment from the being garbage collected,
> assign it to a global variable -- as long as the variable
> holds the environment, it will be safe.  This won't speed
> up the GC.  It's possible to make s7 strings that are not
> seen at all by the GC (make_permament_string), but it's much
> trickier for an environment -- you'd have to be sure that
> every cell of every variable in the environment was
> permanent; otherwise the cell might have no one else
> referring to it, and the GC would free it.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20230430/ebf1ee61/attachment.html>

From bil at ccrma.Stanford.EDU  Sun Apr 30 12:48:27 2023
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Sun, 30 Apr 2023 12:48:27 -0700
Subject: [CM] =?utf-8?q?Protecting_Scheme_data_structures_from_GC=3F?=
In-Reply-To: <CAN9NcLxte6HbZYFt1uL0=kHGT3wQPGw7jyL=du6SpL0HxTmEDw@mail.gmail.com>
References: <CAN9NcLw+nphdALBeScBXDCdgqNdMvWWRm9Ge_yTWjQvvQEZJXg@mail.gmail.com>
	<fe12f9fa334b82cd9e80cb511de25139@ccrma.stanford.edu>
	<CAN9NcLxte6HbZYFt1uL0=kHGT3wQPGw7jyL=du6SpL0HxTmEDw@mail.gmail.com>
Message-ID: <75b2f8ff8decf925fd4a558023d197ce@ccrma.stanford.edu>

> Do you have any suggestions for what one can do to cut GC times down
> on a code level when there is a lot of code going?

Avoid creating things unnecessarily, and don't keep large structures
around when they're no longer needed.  The (*s7* 'memory-usage)
function can show how many objects of each type are currently
in the heap.