[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU ELPA] New package: tam

From: Stefan Monnier
Subject: Re: [GNU ELPA] New package: tam
Date: Wed, 20 Sep 2023 13:30:34 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

>> Re your last change in [0], why use records directly instead of having
>> the code being generated via cl-defstruct?  The commit messages doesn't
>> really explain your reasoning to me.
> The library is supposed to provide alloc/free functions that run in
> O(1) time to the extent that is possible for emacs-lisp code, for use
> in process sentinels and similar situations.  I took a look at the
> byte-code generated for those two functions when using the
> cl-defstruct definitions, and the accessors and setters were
> not inlined.

That's odd.  Could you give more details about what&how you checked that?

> Aside from the unknown complexity of invoking those functions, every
> call has a risk of overflowing the current stack and requiring an
> additional stack segment be allocated.

That would still be O(1) in my book.

> Accumulating a list in the right order is only O(n^2) if you only keep
> the head of the list.  The queue structure (or what I would write with
> let-bound variables) holds a reference to the last cons cell of the
> list to use in adding an entry on the end.  It's probably negligible
> for very short lists, but it's just bad form.

Using `push`es followed by `nreverse` is usually more efficient than
either of those.  It's a standard idiom in Lisp for good reasons.
If you care about the constant of your O(1) above, I recommend you use
`nreverse` here as well :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]