Timeline for Use parallel to speed up a recursive shell max function?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 26, 2021 at 15:34 | answer | added | Ole Tange | timeline score: 2 | |
| Feb 21, 2021 at 5:00 | comment | added | user unknown | @ilkkachu: Well, recursion has become my default way of problem solving, since I learned a bit functional programming. Taking this way was very slow which reminded me, that I wanted to try gnu-parallel for a long time, but rarely had a case, where I thought, it could be helpful, so I gave it a try. Being stuck, I wrote a question here, and while writing, I found the main part of the solution by accident. The remark about the slow bash is only a sidenote.Maybe the case/esac part is exceptionally slow and somebody knows much more than I do? | |
| Feb 20, 2021 at 20:14 | comment | added | ilkkachu | "Is the shell known for poor performance in recursion?" -- depends also on the shell. On my system, Bash takes about 3.5 s for running that with 350 numbers, while ksh takes 0.03 s. There was some other question here at some point about Bash being slow with passing a large number of parameters, but tail-call optimization (or lack of it) might also come into play. Anyway, taking a maximum of a list doesn't strike me as something that inherently requires recursion, other than for splitting it for parallel processing, so I wonder, if that's not your point here, is it just a distraction? | |
| Feb 20, 2021 at 19:49 | comment | added | user unknown | Well, the question was about recursion in the shell, which you omitted. To make fun of the shell? The while-loop is significantly faster, and shell code, too. | |
| Feb 20, 2021 at 19:39 | comment | added | Fox | "Is the shell known for poor performance"? Yes. | |
| Feb 20, 2021 at 18:31 | history | asked | user unknown | CC BY-SA 4.0 |