e_repository_TEST_6 takes almost twice as long as upstream

[piotrrak]

So, on my machine it used to be 50s and after rebasing on this code base I see it timing out with 90s.
I will might take a look why it is that at some point.
More to let you know, than real issue for me.

[negril]

What branch did you rebase? Because everything in here is quite old and I haven't pushed the accumulated changes (yet).

[Ionic]

That surprises me, since there weren't any changes to the EAPI=6 tests for years. Then again, it timing out might indicate an endless loop somewhere.

In any case, I started merging a lot of things on January, but then left it due to work and real life. I'll try to continue next week. It doesn't really make sense to debug stuff if so much other changes are currently missing.

[MageSlayer]

Offtopic.
Glad you are alive, guys.
I thought I've already lost you :)

[negril]

I'm more happy you are still kicking about. I never left in the first place. :)
My changes are in https://github.com/negril/paludis/tree/gentoo/build while I was contemplating how to solve #44.

Re the bug. It's likely related to ebuild_safe_source via loadenv which takes ~75% of each phase of the ERepository6 tests.
It's also code @Ionic touched see https://github.com/MageSlayer/paludis-gentoo-patches/blob/master/paludis/repositories/e/ebuild/source_functions.bash#L37C11-L122.

[Ionic]

But the changes in 133e5d9 shouldn't be all that crazy. Maybe spawning sed instead of the old print_exports binary takes longer, but hardly double the time.

I mean, in the end, keeping that in mind as an optimization issue might be interesting, but we generally really need that change, since Gentoo started using associative arrays and the like.

I initially interpreted "timing out" as an issue, like the execution stopping due to a timeout error. This can't be the case, though, since in my build logs, I can see the test taking 465 seconds on my machine (yeah, older and rather slow by today's standards).

Fortunately, this doesn't seem to the case.

[negril]

For the associative array thing I have a very dirty fix for that seems to work. I'll PR that in the next days.

[piotrrak]

I'll try to perf it, during this week. branch master vs. https://gitlab.exherbo.org/paludis/paludis. I've noticed I do have an (unintentional) change there which may explain some of this regression. Switching internal representation of FSPath to std::filesystem::path. Sorry about raising the alarm, but looked huge 52s vs 92s. Should have been more careful.

[piotrrak]

I do have this change on both versions though.

[negril]

It's likely that it is something bash related.

[piotrrak]

Gonna see just to be sure, but too much overtime today to even attempt - I would mess it up tonight.

[piotrrak]

I can confirm previous findings it is ~48s vs ~91s. Not sure if I will nail down exact issues of this disparency easily, but something can be done for both repos just looking at simple perf report.

Just noticed that dynamic relocations of locked_pipe_command are pretty high:
Such simple change cuts execution time of e_repository_TEST_6 for both repos by pretty nice ~4s but making locked_pipe_command static executable

diff --git a/paludis/repositories/e/ebuild/utils/CMakeLists.txt b/paludis/repositories/e/ebuild/utils/CMakeLists.txt
index bfe61de2a..fdd174bd3 100644
--- a/paludis/repositories/e/ebuild/utils/CMakeLists.txt
+++ b/paludis/repositories/e/ebuild/utils/CMakeLists.txt
@@ -22,6 +22,7 @@ add_executable(print_exports
                  "${CMAKE_CURRENT_SOURCE_DIR}/print_exports.cc")
 add_executable(locked_pipe_command
                  "${CMAKE_CURRENT_SOURCE_DIR}/locked_pipe_command.cc")
+target_link_libraries(locked_pipe_command PRIVATE -static)
 add_executable(strip_tar_corruption
                  "${CMAKE_CURRENT_SOURCE_DIR}/strip_tar_corruption.cc")

This is not my priority at this moment, but can spend some time and try to see what hurts most. If anyone thinks such work is worthwhile.