4 ms·

Not defending this particular example, but there are contexts where avoiding an external call can make a difference. Think a script calling an external program

Not defending this particular example, but there are contexts where avoiding an external call can make a difference. Think a script calling an external program in a deeply nested loop. This sort of optimization could be used as a last resort, after identifying a real performance issue and evaluating the possibility of restructuring the code.

Jenz 7y ago
Would not the chances be, that if in a deeply nested loop, requiring optimization— you’re better of using a "proper" programming language? Maybe Python, or something similar.
- rhizome31 7y ago
  Yes sure, but rewriting a legacy system is not always an option. My experience comes from the scientific computing world where venerable Fortran programs are glued together with huge piles of shell scripts.
james_s_tayler 7y ago
Sure. I don't disagree there is a time and a place. I just never personally encounter those kinds of times or places. I don't doubt they exist and in that case I would definitely agree the correct way to address it would be write the more performant code. I guess my bash uses cases are more just around internal tooling and are never performance critical, so my personal preferences are for readability under those circumstances.
IronWolve 7y ago
I've ran into this decades ago with file servers back. Half a million files, takes too long to do a simple for loop and calling 3rd party processes for awk/sed when I was just using them to format/search text. Breaking it down to just to mosty bash one scripts reduced the run time and ended all pauses.
- Jenz 7y ago
  I was going to argue that it would be better to simply not use a shell for that, but > decades ago Frankly, I can only imagine how the environment then would be. Thinking back with your current experience, what do you think you would have done if you had to fix it again?
  - rhizome31 7y ago
    And the funny thing is that some of these systems are still in use for critical missions. Sometimes even bash isn't an option, you have to deal with older shells like ksh.
  - IronWolve 7y ago
    Things have changed so much, from the app side laying out data, file system/storage side, and hardware speeds, that people are much more lazy with applications due to the environmental improvements. I use to make lists first, then process the lists, I still do this sometimes since its faster. If you have to run a query every time, your probably doing it wrong, but for small stuff, everything is so far, I can chain gnu apps and be done. I'm not a programmer, I'm a sysadmin so mostly deal with the fixing things like auditing or fixing data on a file system. (or maybe db)

Jenz 7y ago

Would not the chances be, that if in a deeply nested loop, requiring optimization— you’re better of using a "proper" programming language? Maybe Python, or something similar.

rhizome31 7y ago
Yes sure, but rewriting a legacy system is not always an option. My experience comes from the scientific computing world where venerable Fortran programs are glued together with huge piles of shell scripts.

james_s_tayler 7y ago

Sure. I don't disagree there is a time and a place. I just never personally encounter those kinds of times or places. I don't doubt they exist and in that case I would definitely agree the correct way to address it would be write the more performant code. I guess my bash uses cases are more just around internal tooling and are never performance critical, so my personal preferences are for readability under those circumstances.

IronWolve 7y ago

I've ran into this decades ago with file servers back. Half a million files, takes too long to do a simple for loop and calling 3rd party processes for awk/sed when I was just using them to format/search text. Breaking it down to just to mosty bash one scripts reduced the run time and ended all pauses.

Jenz 7y ago
I was going to argue that it would be better to simply not use a shell for that, but > decades ago Frankly, I can only imagine how the environment then would be. Thinking back with your current experience, what do you think you would have done if you had to fix it again?
- rhizome31 7y ago
  And the funny thing is that some of these systems are still in use for critical missions. Sometimes even bash isn't an option, you have to deal with older shells like ksh.
- IronWolve 7y ago
  Things have changed so much, from the app side laying out data, file system/storage side, and hardware speeds, that people are much more lazy with applications due to the environmental improvements. I use to make lists first, then process the lists, I still do this sometimes since its faster. If you have to run a query every time, your probably doing it wrong, but for small stuff, everything is so far, I can chain gnu apps and be done. I'm not a programmer, I'm a sysadmin so mostly deal with the fixing things like auditing or fixing data on a file system. (or maybe db)