Re: [PATCH v2] Huge performance boost for recursion (cp, du, find, ls, rm, mv)

On Sat, 11 Apr 2026 at 05:30, Roberto A. Foglietta
<[email protected]> wrote:
>
> On Sat, 11 Apr 2026 at 00:15, Jody Bruchon <[email protected]> wrote:
> >
> > 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.
>
> Without credit isn't good. Anyway, can you provide more information
> about? The code you are talking about isn't into the master branch of
> busybox.net
>

ok, I got the point.


A) This patchset from Sertonix

+ e139ba59e - 2026-03-29 - recursive_action: prevent file type
confusion when files, p.7
+ 0c74c3734 - 2026-03-29 - recursive_action: prevent file type
confusion when files, p.6
+ 1dbddc8a0 - 2026-03-29 - recursive_action: prevent file type
confusion when files, p.5
+ 6a3c6e6ac - 2026-03-29 - recursive_action: prevent file type
confusion when files, p.4
+ ef90136cf - 2026-03-29 - recursive_action: prevent file type
confusion when files, p.3
+ 5a9f95f73 - 2026-03-29 - recursive_action: prevent file type
confusion when files, p.2
+ 0ea29dd56 - 2026-03-29 - recursive_action: prevent file type
confusion when files, p.1

B) conflicts with other patchset from Jody

+ e2d50a648 - 2026-04-02 - cache performance boost for recursion, xmalloc
+ 5cfaaac65 - 2026-04-02 - cache performance boost for recursion, cleanup
+ 198eb0efb - 2026-04-02 - cache performance boost for recursion

This was clear even before, but it wasn't clear that A) includes
changes inspired by B), apparently.

Moreover, A) has IMHO an issue here:

    if (state->depth == 1
     && (  !(statbuf->st_mode & (S_IFREG | S_IFLNK))
        || invalid_name(state->fileName)
        || (!(option_mask32 & OPT_l) && faccessat(state->dirfd,
state->baseName, W_OK, 0) != 0))

Because the run_parts is supposed to execute, not write parts. Why
change the X_OK check?

Moreover, B) has in the comment an output from cache grind.

For this reason, and because it is better dealing with patches (*) I
decided to refactoring some branches:

- bugfixes renamed bugfixes.old
- the pachset A) is moved in 'sertonix' new branch
- the patchset B) has been integrated into 'jodyb2' new branch
- the branch 'bugfixes' doesn't include A) patchset anymore
- the branch 'features' includes b) patchset

I think the correct way to proceed is that Sertonix remade its patch
as "bugfix" providing a v2 based on the 'features' branch in such a
way that the contribution from Jody will be integrated, if it is going
to fix or improve it. Or any other manner to proceed agreed between
Jody and Sertonix.

(*) sorry, I did not have to deal with busybox for years, cold starts
aren't the best...)

Best regards, R-