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 <tr...@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 <s...@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
signature.asc
Description: PGP signature