Re: master 669aeaf: Prefer make_nil_vector to make-vector with nil

[Pip Cet]

On Tue, Aug 11, 2020 at 5:32 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> branch: master
> commit 669aeafbd14b0ebb824bacba0a6b3daad30847a9
> Author: Paul Eggert <eggert@cs.ucla.edu>
> Commit: Paul Eggert <eggert@cs.ucla.edu>
>
>     Prefer make_nil_vector to make-vector with nil

I don't :-)

>  src/lisp.h    | 3 ++-
>  src/pdumper.c | 4 +++-
>  src/timefns.c | 2 +-
>  3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/lisp.h b/src/lisp.h
> index d88038d..2962bab 100644
> --- a/src/lisp.h
> +++ b/src/lisp.h
> @@ -3947,7 +3947,8 @@ make_uninit_sub_char_table (int depth, int min_char)
>    return v;
>  }
>
> -/* Make a vector of SIZE nils.  */
> +/* Make a vector of SIZE nils - faster than make_vector (size, Qnil)
> +   if the OS already cleared the new memory.  */

How is it faster? It calls allocate_nil_vector, which calls
allocate_clear_vector.  make_vector also calls allocate_clear_vector.

If the statement in the comment were true, it would be a bug, because
(make-vector n nil) is something we need to be fast.

(Even if the microoptimization of zeroed vectors is worth it, there's
no reason not to do it transparently in an inline function. Currently
we have make_vector, Fmake_vector, allocate_vector,
allocate_nil_vector, make_uninit_vector, make_nil_vector, and
allocate_clear_vector. I'd say we cut down the complication and use
Fmake_vector almost everywhere).