[PATCH v2] Huge performance boost for recursion (cp, du, find, ls, rm, mv)
Roberto A. Foglietta
roberto.foglietta at gmail.com
Sat Apr 11 07:54:36 UTC 2026
- Previous message (by thread): [PATCH v2] Huge performance boost for recursion (cp, du, find, ls, rm, mv)
- Next message (by thread): [PATCH v2] Huge performance boost for recursion (cp, du, find, ls, rm, mv)
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On Sat, 11 Apr 2026 at 05:30, Roberto A. Foglietta
<roberto.foglietta at gmail.com> wrote:
>
> On Sat, 11 Apr 2026 at 00:15, Jody Bruchon <jody at jodybruchon.com> 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-
- Previous message (by thread): [PATCH v2] Huge performance boost for recursion (cp, du, find, ls, rm, mv)
- Next message (by thread): [PATCH v2] Huge performance boost for recursion (cp, du, find, ls, rm, mv)
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the busybox
mailing list