Hi Tom,
On Wed, 24 Jul 2024 at 16:35, Tom Rini trini@konsulko.com wrote:
On Wed, Jul 24, 2024 at 04:17:32PM -0600, Simon Glass wrote:
Hi Tom,
On Wed, 24 Jul 2024 at 14:54, Tom Rini trini@konsulko.com wrote:
On Wed, Jul 24, 2024 at 11:31:48AM +0530, Sughosh Ganu wrote:
From: Simon Glass sjg@chromium.org
Use this new data structure in the utility function.
Signed-off-by: Simon Glass sjg@chromium.org Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org
lib/strto.c | 35 +++++++++++++++++++---------------- 1 file changed, 19 insertions(+), 16 deletions(-)
This is rather big growth when we didn't already have realloc: 05: lib: Convert str_to_list() to use alist aarch64: (for 1/1 boards) all +1765.0 rodata +37.0 text +1728.0 xilinx_versal_mini_emmc0: all +1765 rodata +37 text +1728 u-boot: add: 7/0, grow: 1/0 bytes: 1728/0 (1728) function old new delta realloc - 1120 +1120 alist_ensure_ptr - 140 +140 alist_expand_to - 136 +136 alist_init - 108 +108 alist_uninit_move_ptr - 76 +76 alist_add_ptr - 72 +72 alist_uninit - 48 +48 str_to_list 204 232 +28
We can just drop this patch, perhaps? It was really just a demo of alist.
Yes, and no. The next good example would be on cortina_presidio-asic-pnand where the reason this series is a size growth rather than reduction (where it is BTW on LTO using platforms) is again, realloc. Is this just an unfortunate given then?
Hmmm maybe. We can of course malloc() and then free() rather than calling realloc(), although that is likely not as efficient. We could have a 'cut down' alist implementation which requires that the initial size be declared, but that defeats the point, really.
Anyway we certainly don't need to apply this patch to strto...there is no particular benefit. I'll leave it up to you.
Regards, Simon