[PATCH v4 3/4] alist: Add support for an allocated pointer list
Tom Rini
trini at konsulko.com
Mon Jul 29 19:46:54 CEST 2024
On Fri, Jul 26, 2024 at 08:54:52AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 26 Jul 2024 at 08:33, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Jul 26, 2024 at 08:00:37AM -0600, Simon Glass wrote:
> > > In various places it is useful to have an array of structures, but allow
> > > it to grow. In some cases we work around it by setting maximum number of
> > > entries, using a Kconfig option. In other places we use a linked list,
> > > which does not provide for random access and can complicate the code.
> > >
> > > Introduce a new data structure, which is a variable-sized list of structs
> > > each of the same, pre-set size. It provides O(1) access and is reasonably
> > > efficient at expanding linearly, since it doubles in size when it runs out
> > > of space.
> > >
> > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > ---
> > >
> > > Changes in v4:
> > > - Avoid using realloc() unless specifically enabled by Kconfig
> >
> > Is this really so performance critical that we can't always just use
> > malloc/free here?
>
> I would have to write some sort of test suite to get a better feel for
> that. The realloc() can be instant if there is space above the current
> item, whereas the malloc() approach always does a copy.
>
> It is certainly odd to use malloc()/free() when realloc() is there, so
> I think it makes sense to provide the option.
Well, we have realloc but generally don't use it. After a quick grep I'm
inclined to suggest we just go without it.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240729/976c8d1f/attachment.sig>
More information about the U-Boot
mailing list