Thread (6 messages) 6 messages, 3 authors, 2022-10-21

Re: "submodule foreach" much slower than removed "submodule--helper --list"

From: Jonas Bernoulli <hidden>
Date: 2022-10-21 14:58:12

Sorry for going silent right after bringing this up.

Ævar Arnfjörð Bjarmason [off-list ref] writes:
I can't reproduce anything like the 8ms v.s. ~600ms difference you note
here, but for me migrating it to a built-in is around 10% slower with
"foreach" than the old "list". I wonder what results you get?
The repository, in which I observed this slowdown, has one hundred
modules.
I sent in a topic to migrate it since you sent this report. I was going
to do it in this development cycle, but this prompted me to do it
earlier:
Thanks!

A lot more is happening here than I can quickly understand, but the last
commit mentions that the slowdown is now just 0.1, which would be good
enough for me, I think.
On Sat, Oct 15 2022, Jonas Bernoulli wrote:
quoted
I just noticed that "submodule--helper name" was also removed, which I
also found useful in scripts.  Please tell me if I am missing something,
but it seems I now have to do something like this instead:

  git config -f .gitmodules --list |
      sed -n "s|^submodule.\([^.]*\).path=$path\$|\1|p"

The old way was nicer:

  git submodule--helper name $path

I realize submodule--helper is for internal use and using it anyway
comes with the risk of such removals and other changes, but again,
please consider restoring that or providing something similar in the
public interface.
This however is another case, I removed "name" along with "list" and
other leftover code we weren't using anymore for the internal-only
"submodule--helper" (which is at turns out, was not as internal-only as
we'd hoped).

For "list" it's clear how to use "foreach" instead, but for "name" then
AFAICT the "best" replacement is to do a:

	git submodule foreach 'echo $displaypath $name'

And pipe that into grep/sed. If that's fast enough would it satisfy your
use-case, or would a "name" equivalent be handy?

I think the best way to prove that would be e.g.:

	git submodule foreach-format '%{name}' -- <pathspec>

Which, due to the "foreach" taking N number of arguments isn't easy to
add to "foreach" without the interface becoming somewhat tortured (we
could add a [---pathspec=<pathspec>]...), but "-- <pathspec>" with a
different subcommand name seems better.
I agree, that adding support for "-- <pathspec>" to an existing or new
subcommand, would make it unnecessary to bring back a "name" subcommand.

Will "foreach"/"foreach-format" continue to be limited to active
modules?  Sometimes it would be nice to list all modules, including
those that are inactive.  As mentioned earlier "git ls-files -s | grep
^160000" is enough to get a list of the module paths, but sometimes we
want more information, e.g., "git submodule list --include-inactive
--format '$name $is_active submodule.$name.url' -- <pathspec>".

     Jonas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help