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

I do not wish to contribute any further.

On 2026-04-11 3:54 AM, Roberto A. Foglietta wrote:
> 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-