Date: Wed, 18 Nov 2020 22:39:44 +0000 From: Jessica Clarke <jrtc27@freebsd.org> To: Stefan Esser <se@freebsd.org> Cc: Mateusz Guzik <mjguzik@gmail.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r367813 - head/lib/libutil Message-ID: <E1B6A5BE-DF00-42D7-B31D-1F4C5D9CBB7D@freebsd.org> In-Reply-To: <ba78fdf4-3b64-8b8e-73a1-4198109db1ef@freebsd.org> References: <202011181944.0AIJiUU3003699@repo.freebsd.org> <CAGudoHEYEZaBTDi_wPdsAc4BkDA6cBfYgxtVw4qEATt62UUPrA@mail.gmail.com> <ba78fdf4-3b64-8b8e-73a1-4198109db1ef@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 Nov 2020, at 22:32, Stefan Esser <se@freebsd.org> wrote:
>
> Am 18.11.20 um 22:40 schrieb Mateusz Guzik:
>>> +{
>>> + static const int localbase_oid[2] = {CTL_USER, USER_LOCALBASE};
>> There is no use for this to be static.
>
> Why not? This makes it part of the constant initialized data of
> the library, which is more efficient under run-time and memory
> space aspects than initializing them on the stack.
>
> What do I miss?
What is more efficient is not so clear-cut, it depends on things like
the architecture, microarchitecture and ABI. Allocating a small buffer
on the stack is extremely cheap (the memory will almost certainly be in
the L1 cache), whereas globally-allocated storage is less likely to be
in the cache due to being spread out, and on some architecture/ABI
combinations will incur additional indirection through the GOT. Also, 8
bytes of additional stack use is lost in the noise.
Jess
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1B6A5BE-DF00-42D7-B31D-1F4C5D9CBB7D>