Re: Identifying sources of allocations in a toy Mandelbrot package

[Eli Zaretskii]

> From: Psionic K <psionik@positron.solutions>
> Date: Fri, 19 Jan 2024 18:19:55 +0900
> Cc: incal@dataswamp.org, Eli Zaretskii <eliz@gnu.org>
> 
> Most importantly to my question, how can I identify sources of consing
> without just knowing which functions and macros pathologically cons?

Insert calls to garbage-collect, and look at the value it returns.

> Is there a way to allow usage of stack by the byte or native compiler?

Lisp objects are not allocated on the stack.

> > and a lot of nested iteration
> 
> I would have expected this to consume only stack memory

Any temporary Lisp objects will allocate memory.  Their references
will be on the stack, but the objects themselves will be on the heap.

> Perhaps concerning is that Emacs continues to consume the same
> resident memory, about 2.1GB, indefinitely after the first run.  Is
> this simply expected from a sprinkling of objects that Emacs cannot GC
> and therefore never give back memory?

The memory is released and available for subsequent allocations, but
not necessarily given back to the OS.  Whether and when to give memory
back to the OS depends on the internals of the C library your Emacs is
using.

> Is this unique to floating points?  Do I still have latent consing in
> this version?  Thanks in advance.

I don't think I understand what you are asking here, please elaborate.