Re: [PATCH v2] Huge performance boost for recursion (cp, du, find, ls, rm, mv)
Jody Bruchon via busybox <[email protected]> Fri, 10 Apr 2026 18:15:11 -0400
| Newsgroups | gmane.linux.busybox |
|---|---|
| Message-ID | <[email protected]> |
Thanks for trying to help. It's OK, I realize that someone already "merged it" with my original code locked in an #if 0 block and a differently optimized version applied without credit, so I consider this matter closed. Please feel free to purge it. I'm not interested in contributing to the project further. On 2026-04-09 4:31 PM, Roberto A. Foglietta wrote: > On Fri, 20 Jun 2025 at 15:39, Jody Bruchon <[email protected]> wrote: >> Bump on this patch? It's been more than a year and this makes a pretty >> big difference for 255 x86_64 bytes. >> >> On 2024-04-15 10:10 PM, Jody Bruchon wrote: >>> This revision reduces code size in concat_path_file_fast() by 19 bytes. It also applies the new get_d_namlen() optimization to a readdir() loop in runit/svlogd.c. >>> >>> If there are any changes that need to be made for inclusion then please let me know as soon as possible. I'd like to finish this project up. If the old/slow and new/fast code should be chosen with a compile-time config option then I'm happy to do that as well. > Previously I integrated your patch into the 'features' branch and then > I merged it on top of bug fixes (or vice versa, it is the same) to > create a branch for my personal use named 'uchaosys'. Unfortunately, > because the time passed and bug fixes accumulated. Something is broken > and thus I moved your patch on a specific branch 'jodyb' > > Merge branch 'features' into jodyb **broken** to complete > The main issue isn't the conflict on two files: > > - libbb/recursive_action.c > - libbb/remove_file.c > > but chmod and in general recursion doesn't work properly. > A negative test case emerged in booting uchoasys #e911a46 > tag _jb_ in which chmod +x /etc/init.d/rcS at init time. > > https://github.com/robang74/busybox/tree/jodyb > > I hope this feedback helps you to update your patch in a way that > integration will not break anything that previous and pending bug > fixes are going to mix-up. > > Best regards, R-