GNU bug report logs - #54532
Faster sorting

Previous Next

Full log

Message #26 received at 54532 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: acohen <at> ust.hk, 54532 <at> debbugs.gnu.org
Subject: Re: bug#54532: [PATCH] sorting
Date: Thu, 24 Mar 2022 08:42:39 +0200

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 23 Mar 2022 21:24:16 +0100
> Cc: Andrew Cohen <acohen <at> ust.hk>, 54532 <at> debbugs.gnu.org
> 
> > Can you tell more why this was needed? Emacs has conservative stack marking, so any Lisp object that is referred by some stack-based variable should be protected from GC. Why isn't that enough in this case?
> 
> Because Lisp values are temporarily moved out to a heap allocated buffer which isn't traversed by the stack scanner. `record_unwind_protect_ptr_mark` can be seen as a generalisation of `record_unwind_protect_ptr` (because that's what it is).

I understand that these objects are on the heap, but AFAIU a reference
to them is on the stack, isn't it?

> > Is this really eassume, or is eassert better here?
> 
> No, eassume is appropriate here. It provides more optimisation opportunities.
> In fact, most uses of eassert are better or just as good as eassume as long as there are no function calls or tricky memory dereferences.

I asked about a specific instance, not in general.  That instance was
at the end of the function, right before it returns, and I wonder what
kind of optimization opportunities that could present.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.