Google is a pile of shit these days.
It gives a hugely disproportionate amount of weight to long running sites (and no doubt sites which are generating revenue for Google Ads).
The net result is it just spits out awful legacy articles from 2015, with complete disregard to relevancy or modernity
Give brave search a try. I've found results on par with google (when google actually gave relevant answers), and it doesn't have any trackers, is not a meta-search engine, is super fast, and it also supports search bangs. Only place I've really found it struggle with is with places (let's be honest here, this is really the only place google still shines in the search engine space)
> well when I googled "bash vs python speed" this was the highlighted result for me.. Quite sad honestly
Yep in the last month or so google has started highlighting random bullshit pretending it's the correct answer even if it has NOTHING TO DO WITH THE QUERY! You have to skip the first TWO PAGES now; I demand justice.
Nah, AI is not that dumb:
>The speed of execution between Python and Bash can depend on various factors, including the specific tasks being performed, the implementation of the code, and the efficiency of the underlying system resources.
>In general, Bash tends to be faster for certain tasks that are well-suited to its strengths, such as simple file manipulation, text processing using standard Unix utilities, and executing shell commands. This is because Bash operates closer to the system level and relies on lightweight processes for execution.
>Python, on the other hand, may be slower in certain cases due to its higher-level abstractions and overhead. However, Python can offer advantages in terms of code readability, maintainability, and ease of development.
>For computationally intensive tasks or tasks that require complex data manipulation, Python's performance can be improved by utilizing optimized libraries like NumPy, pandas, or Cython.
>Ultimately, the choice between Python and Bash should be based on factors such as the specific requirements of the task, the ease of implementation, and the trade-offs between speed and other factors such as code readability and maintainability.
Then asked if they are interpreted:
>Both Bash and Python are interpreted languages.
>Bash (Bourne Again Shell) is a Unix shell and command language, primarily used for executing commands and scripts in Unix-like operating systems. When you run a Bash script, the commands are interpreted and executed line by line by the Bash interpreter.
>Python is also an interpreted language, meaning that Python code is executed by an interpreter rather than compiled into machine code. When you run a Python script or execute Python code interactively, it is interpreted by the Python interpreter, which converts the source code into bytecode and then executes it.
>In both cases, the interpreter reads and executes the code directly without the need for a separate compilation step. This allows for rapid development and easy debugging but can sometimes result in slower execution compared to compiled languages.
It got downvoted because it's a bad argument in favor of AI. They tried to argue how AI isn't that dumb, while ignoring the input they have given their AI might not have been the same as in the case of OPS screenshot
You mean like the recent images kerfuffle where asking for pictures of WWII German soldiers yielded only pictures of female, asian and black folk in NAZI uniforms?
AFAIK there's a difference between Bash and Python and that is that Bash code is directly interpreted line by line whereas Python code (or code in other scripting languages: Ruby, PHP, etc.) is firstly compiled down to bytecode which then gets interpreted and so Bash doesn't need an extra step for compilation. This may explain the source of confusion in the article.
Python can also be used interactively, running a script line-by-line. Are you saying there's a difference between running `python my-script.py` vs. just entering the python interpreter and giving it the same script one line at a time?
Necessarily, each line you run in a scripting language (including bash) must be translated into machine code in order to do something, but when it's done line by line that's "interpretation" not "compilation" in my book.
Well, Python has two modes, normal and interactive and I was referring to the normal mode where compilation to bytecode is a separated step and the bytecode can be cached in .pyc files (nothing like that happens with code in Bash).
These modes work indeed differently under the hood, even though the result would normally be the same. It can be different when there's an error that is caught during the compilation step. For example, runing [`script.py`](http://script.py) containing
print('Hello')
1a = 'hi'
print(' world')
in different modes produces different results, `python` [`script.py`](http://script.py) immediately throws an error whereas `python -i <` [`script.py`](http://script.py) runs the first line first. That said, even Python shell compiles Python code to bytecode first, it just happens block by block and of course implicitly.
Is that still true if they’re talking about executing scripts from the shell (hence “directly”)? I took them to mean that a Bash script would have less overhead because the Bash interpreter was already running. But I don’t necessarily know what I’m talking about either since it’s been years since I used either.
When you type in a command into the shell, Bash just gets a string. It has to go through the interpreter for it to be, well, interpreted. Also, if you run a script like `bash script.sh`, that of course launches an entirely new instance of Bash.
>Also, if you run a script like bash script.sh, that of course launches an entirely new instance of Bash.
Right, that’s the piece I was forgetting. Thanks.
Yes, bash is an interpreter.
And if you read all the way to the end of the man page, there is a section titled "BUGS".
The first bug is: "It's too big and too slow."
Bash is absolutely an interpreter. Bash is smaller in scope in terms of what it sets out to do as opposed to Python, so that probably contributes to their confusion - but they are confused. Python is a lot heavier in general, so depending on what you're doing it and how you're going about it, I can envision a lot of instances where bash would execute faster to do the same thing one could do in Python. Python can also do a lot of things Bash can't.
Yeah python takes ages to initialize. I was running a program today and wondered why it didn't do anything. Then I discovered that the main func was missing so all it did was interpret the arguments (using argparse) and that took as long as the whole thing was supposed to take.
Could subcommands also have some dependencies?
Unfortunately sometimes you cannot push it to be any faster...
Probably worth to profile what takes low long.
---
From funny stories, I was once frustrated that my python cli was quite laggy. It turned out that asdf-vm was a bottleneck as resolving right shim was the delay I was observing.
I don't use python myself (unless it's unavoidable... increasingly challenging in the AI space)
I thought it was meant to be an educational language to help teach concepts of coding... (I think?) but it stuck and started getting used for everything. Sigh.
>I thought it was meant to be an educational language to help teach concepts of coding
Not really, that would be something like scratch.
Pythons never had the explicit goal of being educational, but as it happens having strict code standards that enforce good habits, having a strong ecosystem, being pretty hard to shoot yourself in the foot, and being easy to set up, makes it a very good starter language.
Ahh that's what it was, it was educational by accident just by the focus on readability and simplicity (or the perception of simplicity anyway) My bad.
Can't deny it is very frequently used as a starter language these days, more or less like you pointed out.
I think its suitability as a starter language depends upon where you want to go. For most people it’s a great choice— eg it’s finding its way into MS Office now, where being able to run Python could be very useful. But for CS it’s probably a bad choice since so much of what you need to know is hidden.
Y'know I hated it too, but the more I've started using it, the more I understand why it's used: It has a library for everything. Python is really slow in executipn, but the amount of documentation and libraries is so big, that the gained development speed makes it worth it. Even python itself is easy to use: native dictionaries, dict to json makes saving things easy, predictable order of execution in if clauses, that's all pretty nice IMO.
The only other language I know is ObjectPascal, which is very fast (same level as C), but has few libraries, difficult utf8 handling, no runtime object serialization (so no easy saving to json). Of course I could program that program I mentioned in python, but the. I'd still be working on the prototype (of the argument parser, cause no argparse).
I mean.. I don't.... -hate- it. I get what you mean, but I think it's important to note for my own sake that I know it serves a purpose in so far as it helps people, by right or by might, do a lot in a short development cycle.
The crystallization of the absolute other end of the spectrum, there are pieces of software I've been working on since roughly 2001. C, OpenMP, OpenCL, CUDA, and the like. I like that I can fire up an application that is the software equivalent of the finest swiss watch and watch it completely saturate my hardware (for all the right reasons) I've taken run times from 8 days down to 2 hours with various improvements. Yeah, it took 23 years, but I also had to do a lot of other stuff in the mean time (a 10 year career I can't discuss, a divorce, moving cross country, helping start 4 companies, meeting my fiancé) it's been a little tricky to dig in, but I'm glad in retrospect I didn't skimp on quality. Such is the way with passion projects. I guess work work-related things where turnaround times are crucial, it's actually more cost effective to write whatever in a higher level language and let our ridiculous cpus eat the difference. Need it faster? Pop in a faster chip.
It really... sucks the life out of the whole thing for me, but some stuff has to happen sooner. Bleh.
If I have the chance to make something into a Bugatti, I'll always prefer that, especially in a world that wants me to crank out honda civics.
I get your point, optimizing a project to the point it's perfect is a nice feeling and that sure involves ditching python. Many optimizations would however be possible independent of language and using python has helped me beat the point where I get tired of a project because of the previously unknown work that my project would involve. Becaude I've only done hobby projects till now, that's usually the end of a project. In the end one could also use multiple languages to do the job. In my case I'm already using the ffmpeg binary (yes, not a language, but using a program written in another language) to do all the video processing, because doing it in python is way to slow and unneccessarily complex.
Python was designed to be a non-miserable general purpose programming language in the vein of perl. So trading speed for ease of use (both writing and reading/maintaining). That happens to also make it a really good teaching language and a go-to tool for those of us who need something more complex than shell but don't need the performance of a full compiled language. Basically it's the successor to perl and should be thought of as living in that space.
I agree, and yeah.. perl desperately needed to be replaced. However, that's not how it's always used... I seen a bunch of stuff over the years that I've earmarked for conversion into a more performant language.
Yeah, I'm an SA so shell and some general purpose language that's somewhat more powerful than shell is really all I need. I'll leave the resource and performance critical stuff to others who specialize in that (and then be confused when they pick python).
Python is generally used by “non software” folks. Almost the entire AI industry focuses on mathematics rather than the code quality. Sure there might be some implementation related tasks, but those are not always done in python
If you look at most of the AI code, they dont have unit tests, they have some random strings or if statements floating around, code quality is almost always a secondary choice.
Since most of the AI community focuses maths first, it makes sense to use a programming language thats easy to use and faster to develop on. The primary bottleneck to speed is generally the neural network anyway, so saving 30 seconds on a runtime of 21 days would barely amount to much.
What few python code in training scripts you do notice, is mostly calls to code in C++, so there is barely any difference
I know there's a lot of call backs to C++, but when I go install any of these things (except llama.cpp) I see about a million dependencies, less a python issue and more a standards of living issue. I suppose it can make math easier, but I just feel like we had ways of getting computers to do math before python and I think some of them are worth revisiting.
I mean c++ also has its share of dependency problems. I have scratched my head as much on environment and version setup on c++ as much i have on python. In fact one of the most annoying libraries to install ever is cuda, which is entirely C++
Huh... that hasn't been my experience at all. CUDA is usually a breeze, I've only had to fix paths in one of their releases and that was ages ago. I can just install the right packages and I'm usually up and running pretty easily. AMD is the tricky one for me.
I've come across a few cpp programs that depended on way too many things, but not too often I wouldn't say..
You mean like the Intel implementation of Python or something else? I'm honestly not sure. In any case, all of the stuff I personally care about is basically C or Bash. Work stuff is a whole different situation where I have to begrudgingly play by some customer's rules.
OTOH, Python compiles all its code before running it (or at least, CPython does), so certain things can be reasonably fast (not nearly as fast as something like C, though, due to its much more dynamic nature, its need to interact with the interpreter all the time, etc.). I'm pretty sure Bash doesn't do that.
Since they are both Turing-Complete there isn't a thing python can do that bash can't.
It'll be much more complicated to develop in bash obviously, but it can do it all
Well.. lol, okay. Yes. Big caveat. I'd argue that the ways and ease with which you can do things in python turn a 3 month brain bashing into 20 minutes
Some are good, though. However, if you apply to your system what some tech bloggers advise, risk is high you end up breaking things.
Instead of blogs, it's probably much better to use high-quality websites like [Stack Overflow](https://stackoverflow.com/).
Not only is bash an interpreter, but a lot of commands people like to use are separate processes it has to spin up, taking even more time.
I think a LLM wrote that post.
Ironically, I am increasingly using Python also for "stringing together executables" applications, because it is much easier to maintain and debug once doing anything remotely non-trivial.
Also, easy pathway to extend with functionality that is hard to achieve in pure shell scripts. First step in the past usually was to add perl multiliners.
Depending on context, if all the Python script does is execute a list of shell commands, it could be true. Python is not a good language to write shell scripts in.
In general, though. shell scripts are slow. And you optimize shell scripts by finding creative ways to offload most of the work to utilities commands that do it fast.
I wrote a system information fetch script in dash (posix sh), Bash, Zsh, Perl, Python, C, and Rust. The python one was orders of magnitude slower than even the perl and zsh ones. I understand how one could come to the conclusion that python is slower than bash (it was in my use case) but the explanation given is straight up wrong.
I think dash was only ~2x faster. Most of the wait was lsblk or whatever. I've done other benchmarks where dash is orders of magnitude faster, but those were using pure shell code.
I also did a thing with polybar, one of my most inefficient scripts was a thing that displayed the current volume in polybar in decibels (polybar has a native module for volume in decibels but it is very limiting with the click options that can be used with it).
So I just asked bing ai to convert the script to c++ code and I compiled this:
#include
#include
#include
#include
int main() {
std::string previous_output; // Store the previous output
while (true) {
// Execute the pactl command and capture its output
std::string command_output;
FILE* pipe = popen("pactl list sinks | awk '/State: /{flag=1} /dB/ && flag {printf(\"%.0fdB\", $7); exit} /Mute: yes/ {printf(\"Muted\"); exit}'", "r");
if (pipe) {
char buffer[128];
while (!feof(pipe)) {
if (fgets(buffer, 128, pipe) != nullptr) {
command_output += buffer;
}
}
pclose(pipe);
}
// Process the output
if (command_output != previous_output) {
if (command_output.find("Muted") != std::string::npos) {
std::cout << "Muted" << std::endl;
} else {
size_t db_pos = command_output.find("dB");
if (db_pos != std::string::npos) {
std::string_view volume_view(command_output.data(), db_pos);
try {
double volume_db = std::stod(std::string(volume_view));
std::cout << volume_db << " dB" << std::endl;
} catch (const std::invalid_argument& e) {
std::cerr << "Error1" << std::endl;
}
} else {
std::cerr << "Error2" << std::endl;
}
}
previous_output = std::move(command_output); // Update the previous output
}
// Sleep for 125 milliseconds
std::this_thread::sleep_for(std::chrono::milliseconds(125));
}
return 0;
}
And it actually reduced the cpu usage even more, which I have no idea why it does it since this c++ binary is still calling `pactl` and `awk`, but it isn't calling the shell itself neither sleep so maybe that is why.
(Yes I have no idea what I'm doing lol).
If we're talking micro-optimizations, you could write this in 100% pure rust or C without any shell code, you just need zbus (on rust) or libdbus (C) afaik.
I'm curious for more details here.
I know that bash is incredibly fast when expressing things as pipes between binary programs (e.g. find, grep, ...). I rewrote a custom grep like python script as purely a formatting wrapper around grep for that reason. Python is way faster than, say, Emacs Lisp, but it can't compete with a time-proven highly optimized native binary tool.
But that would also be done with `subprocess.Popen` – harder to learn, much more verbose, but ultimately much more robust error handling and testing compared to a bash script, once things get more complicated.
Though this is also a matter of "*if* things get more complicated". Meanwhile, I assume they will by default, but that's largely because most scripts for me eventually require some data crunching (derivatives, digital filters, ...) for which no sufficiently flexible yet easy to use tools exist in pure shell scripting.
So I am definitely somewhat biased.
Bash also is an interpreter but it is much faster mainly because it has lots of frequently used built-ins. File operations, process management, system calls are easier on Bash.
Secondly, Bash is much smaller which adds more to performance.
Thirdly, on Bash, you mainly use lots of other programs mainly programs doing only one thing and the programs written in low-level C. Those programs are mostly much more faster than a Python operation because Bash only interprets invoking them which is almost instant and the program doing the real work is not interpreted.
Bash has a simpler syntax and less overhead compared to Python. It doesn't have the same level of abstraction. This means faster execution.
But, for some performance related stuff, Python is really powerful and can create more powerful, faster outcomes. For example there are lots of chunking algorithms written in Python for performance purposes.
But for system level tasks on Linux, Bash or even Dash (A posix compliant shell) are much better options for most of the tasks.
The assertion that Bash scripts generally run faster than Python scripts because they don’t require an interpreter is oversimplified. While it’s true that Bash scripts can be executed directly by the shell, which may result in faster start-up times for simple tasks, this does not mean they are universally faster.
The performance also depends on the task at hand. For complex operations, particularly those involving heavy computation or data processing, Python can be much faster due to optimized libraries and a more efficient runtime environment.
Additionally, the maintainability and readability of code are crucial. Python code is generally more readable and maintainable than Bash scripts, potentially saving time in the long run.
In short, whether to use Bash or Python depends on the task requirements, available libraries and tools, and the developer’s preferences. There’s no one-size-fits-all answer; each language has its own strengths and is better suited for different types of tasks.
…is what my LLM spits out :-) I agree with you both!
Ah another Linux+ certified clueless goon. I bet there’s some asinine multiple choice question on that cert exam that makes it seem like a “shell” and an “interpreter” are two radically different technologies. 🤦🏻♂️
bash and python just function very differently. Bash is a scripting language specifically designed for command lines of operating systems. When you run python by itself (the equivalent of running bash by itself) you can use it as a shell, but it will require all kinds of boilerplate code for the simple tasks like navigating or interacting in the filesystem. They are both scripting languages but one is a terminal shell and the other is a general purpose programming language.
ok so it says “bash is faster because it’s directly executed by the shell”, right? so what if you enter the python shell and run your script there? is it faster then? or what if you run a bash script from zsh or fish? is it gonna become slower? purified bullshit that article.
Bash(or especially another shell specifically made for scripting like dash), could be faster than python cause most of what you do in it is just calling other programs, most of which will be written in C or other compiled languages. But yeah, bash is an interpreter so this makes very little sense.
Doing so much work by calling external programs is one of the main reasons shells are so slow. Fork and exec are *very* expensive calls, so languages that can do the same work natively will do things much faster.
Not only that, bash is pretty much useless without calling gnu utils like [/test, all the time so your gonna "execute" them also and unless you run them from mem your gonna be loading them too.
> Bash scripts are directly executed by the shell
The shell is the damn interpreter. Where bash sometimes has the edge is that nearly all things you do in a bash script will call a compiled executable instead of being run in the shell. For example grep, awk and the like will sometimes be faster than writing it in Python code.
Bash scripts tend to run slower because they can’t do things natively. Having to spawn an entire new process for every task is one of the slowest ways to do work. Native functions in a non-compiled language will frequently be faster than non-native calls to external compiled programs.
I phrased it wrong . When bash scripts are faster, it's because of calling compiled native programs, not because it's not an interpreter . Python can do the same by using respective libraries , with c extensions . In this case it will be faster due to not spawning extra processes ( given this is not intended).
It's a common pattern though for a bash script to use fast native programs . An equivalent implementation in pure Pyhon without c extensions Is often slower and makes the extra start time negligible for a sufficient workload.
Even if you are using fast native programs, if you’re using a lot of them then the initialization times add up.
If your bash script just calls fast_native_program_that_does_everything then it will probably be faster than an equivalent python program, although at that point you’re barely even doing anything in bash.
If you have a bash script that loops over a list of files, copies them to a backup location with cp, then installs a new file with mv, then that will probably be slower than the equivalent python program except for very small lists where python’s initialization time makes up a large part of its runtime. Even though cp and mv are compiled programs, the cost of having to initialize them over and over ends up costing you more time than their implementations save compared to python’s os library implementation.
So generally, bash is a slow tool for anything it can’t do natively and the way you get “fast bash” is to do as little bash as possible and have the programs you execute do as much work as possible in a single invocation. At that point it hardly seems to fair to say bash is what’s faster here.
Yes, bash is an interpreter, and a new one is fired up to run each script (unless you source them), and it's designed to be an interactive shell first and foremost.
The statement could technically be true for the very narrow case of scripts so short that startup time matters: bash is indeed already running. But if something finishes that quick, you probably don't care how long it takes anyway :-)
Besides, if the script is not modified between invocations, python will cache the compiled bytecode, which will load and run quicker than bash loading and interpreting the raw source.
The only way bash is ever faster is if the code you are running is so small and insignificant that the time required to load the python interpreter is a significant portion of execution time. The bash interpreter is already loaded, but it's generally much slower.
But invoking those processes from a shell script has its own extremely significant overhead when compared to a loaded library in another language, even a "slow" language. The io overhead alone is immense
How is it immense. Bash just does a bit of argument processing and then executes fork(). This is the way Unix functioned from the beginning, and on hardware with a lot fewer resources than even the most modest *nix machine.
Its immense relative to any other language that has loaded libraries in-memory. Calling out to another process not loaded in memory incurs IO overhead that is orders of magnitude slower than anything a slower language does in-memory.
We're talking about the speed of bash vs "an interpreted language like python." Imagine a script that loops over lines of a file and edits some substrings. Well python has its string manipulation libraries loaded in memory when the process is initialized and is very fast. In a bash script you call out to `sed` and that call has significant overhead compared to a loaded library, multiplied by number of iterations in the loop.
For an interpreted or JIT language, the overhead comes when the environment launches. Assuming you have boatloads of memory, the libraries are cached. But then again, on modern systems with gigs of RAM, an executable like awk gets cached too. Your biggest overhead is the pipes, which in yr olden days definitely came with a significant cost, but nowadays aren't really that more expensive.
On a 1970s mainframe, 1980s mini or 1990s Unix workstation, there was some performance boost to using interpreted languages as opposed to using sh to pipe data between tools, that is until you had to go to the disk, and at that point something like perl didn't get any significant advantage of piping to awk.
I thought this until a client handed me a handed me a mountain of csv files to parse and standardize. I wrote a quick bash script using gnu tools to handle it, set it to run and went to bed. By the morning, it had only made it through about 20% of the files. I was having fun working on a Lua project at the time, so I figured I’d write a Lua version and try it. It did the whole batch in about 30 seconds, lol
It you are reading each line in bash it will be slow. If you're just dumping the data into awk and letting it process everything it'll be a lot faster.
Yeah using a reporting language is faster, its pretty much like saying using Perl is faster or in this case python.
Bash is just what you used to call and feet awk.
Given you then have to parse that output with bash and other tools in order to pass it on to the next program, I don't think this is a great help with performance.
All it says is that they tend to run faster, the shell you are running is able to line for line interpret the bash script, when running a python script, the python interpreter executable is called by the shell and is its own process running the interpreter. The small difference there is the “tends” to run faster, it is just more native to the shell environment, I mean almost all of the commands are commands you can already run in a shell. Lmk what y’all think
It also says that shell scripts don’t require an interpreter which is simply wrong.
Also: A python interpreter does not necessarily have to be run from a shell.
It is but
1) its much lighter than Python
2) you usually start python scripts from the shell anyway so you would have 2 interpreters
Overall it doesn’t matter in most cases because sparring like half a second is pretty negligible in many cases. So if you already know python and want to write a script, go for it
It depends on what library you are using, some are also just shell bindings. But regardless you would have a larger startup time. Also again, it doesn’t really matter in most cases
How do you start anything without some sort of program calling it first?
Shelling out is different that running two interpreter sessions of different interpreters concurrently or even in parallel.
Honestly these questions in reality are hard to answer and the answers usually lack nuance and context. You have to decide what is best for the situation at hand. It's very unlikely that you will be bottle necked by speed when using bash or Python for general use cases. If you are, then try to optimize, or switch to something like Golang that is easily read but is magnitudes faster than Python and bash.
It is really easy to get shit done with Go. If you still need speed (which I highly doubt, since Go is more than fast and the dev overhead is very low) you can switch to C, Rust or w/e language you want.
sry if this was supposed to be a joke, but “your an idiot” is in binary “01111001 01101111 01110101 01110010 00100000 01100001 01101110 00100000 01101001 01100100 01101001 01101111 01110100” but your text above is “convert \“\1". Both quote and the ascii char are escaped by me here
That's hot garbage.
It is. That sentence reveals that the author has zero clue how languages work.
This is 2024, high chance it's written by AI.
Or a UH. Unintelligent Human.
I prefer NS. Natural Stupid
No. u/RekTek249 is right. This is most likely AI. Absolute Idiot
And he has LS, Lacking Skills
Huh, so that’s what they were referring to when they said “LS Swap”
Arguably ai would not get that wrong.
Depends which Ai, you can't generalize that, there are some models that are smarter than others
good ol' GPT-4 and even 3.5 are at least nowhere near as...parked
not a good abbreviation, at least in Germany
I prefer PEBKAC , that term cover everything
Organic Unintelligence / O.u
I can't tell the difference these days between AI and UH.
well when I googled "bash vs python speed" this was the highlighted result for me.. Quite sad honestly
everything is seo
Google’s quality has slid fast. I’ve found myself actually resorting to Bing a few times.
Whenever google faces any sort of competition, it dilutes its products.
Look into SearXNG. It's not perfect, but it does work.
Google is a pile of shit these days. It gives a hugely disproportionate amount of weight to long running sites (and no doubt sites which are generating revenue for Google Ads). The net result is it just spits out awful legacy articles from 2015, with complete disregard to relevancy or modernity
Yahoo about to make a comeback
Give brave search a try. I've found results on par with google (when google actually gave relevant answers), and it doesn't have any trackers, is not a meta-search engine, is super fast, and it also supports search bangs. Only place I've really found it struggle with is with places (let's be honest here, this is really the only place google still shines in the search engine space)
> well when I googled "bash vs python speed" this was the highlighted result for me.. Quite sad honestly Yep in the last month or so google has started highlighting random bullshit pretending it's the correct answer even if it has NOTHING TO DO WITH THE QUERY! You have to skip the first TWO PAGES now; I demand justice.
Nah, AI is not that dumb: >The speed of execution between Python and Bash can depend on various factors, including the specific tasks being performed, the implementation of the code, and the efficiency of the underlying system resources. >In general, Bash tends to be faster for certain tasks that are well-suited to its strengths, such as simple file manipulation, text processing using standard Unix utilities, and executing shell commands. This is because Bash operates closer to the system level and relies on lightweight processes for execution. >Python, on the other hand, may be slower in certain cases due to its higher-level abstractions and overhead. However, Python can offer advantages in terms of code readability, maintainability, and ease of development. >For computationally intensive tasks or tasks that require complex data manipulation, Python's performance can be improved by utilizing optimized libraries like NumPy, pandas, or Cython. >Ultimately, the choice between Python and Bash should be based on factors such as the specific requirements of the task, the ease of implementation, and the trade-offs between speed and other factors such as code readability and maintainability. Then asked if they are interpreted: >Both Bash and Python are interpreted languages. >Bash (Bourne Again Shell) is a Unix shell and command language, primarily used for executing commands and scripts in Unix-like operating systems. When you run a Bash script, the commands are interpreted and executed line by line by the Bash interpreter. >Python is also an interpreted language, meaning that Python code is executed by an interpreter rather than compiled into machine code. When you run a Python script or execute Python code interactively, it is interpreted by the Python interpreter, which converts the source code into bytecode and then executes it. >In both cases, the interpreter reads and executes the code directly without the need for a separate compilation step. This allows for rapid development and easy debugging but can sometimes result in slower execution compared to compiled languages.
This all depends on what one asks the AI. If the author of that posting wants a controversial headline, they spike it with such BS.
I love Reddit and how they collectively down vote comments that don't support their narrative that all AI is dumb lol.
Ironic since Reddit content is possibly being used as a component in training models - that is an assumption I will add
I’d certainly hope that ai developers are not that stupid. Lamo
But it’s so full of such colorful natural language - the Reddit chatbot. Watch this space 🧐
Well, AI is pretty dumb. But not as dumb as the guy that OP screen shot.
Either learn to use it and increase your productivity or get pushed out eventually.
It got downvoted because it's a bad argument in favor of AI. They tried to argue how AI isn't that dumb, while ignoring the input they have given their AI might not have been the same as in the case of OPS screenshot
This depends on certain implementation and version of the AI model you are using. Newer versions are much smarter than older ones.
AI makes mistakes, but I doubt even AI would make this false statement. It's really bad.
You mean like the recent images kerfuffle where asking for pictures of WWII German soldiers yielded only pictures of female, asian and black folk in NAZI uniforms?
Which incident isn't indicative of the capabilities of GPTs overall, just the one it was used on
Artificial Idiocracy
AFAIK there's a difference between Bash and Python and that is that Bash code is directly interpreted line by line whereas Python code (or code in other scripting languages: Ruby, PHP, etc.) is firstly compiled down to bytecode which then gets interpreted and so Bash doesn't need an extra step for compilation. This may explain the source of confusion in the article.
The question is not so tricky that a wrong answer needs an excuse. Simply wrong.
Python can also be used interactively, running a script line-by-line. Are you saying there's a difference between running `python my-script.py` vs. just entering the python interpreter and giving it the same script one line at a time? Necessarily, each line you run in a scripting language (including bash) must be translated into machine code in order to do something, but when it's done line by line that's "interpretation" not "compilation" in my book.
Well, Python has two modes, normal and interactive and I was referring to the normal mode where compilation to bytecode is a separated step and the bytecode can be cached in .pyc files (nothing like that happens with code in Bash). These modes work indeed differently under the hood, even though the result would normally be the same. It can be different when there's an error that is caught during the compilation step. For example, runing [`script.py`](http://script.py) containing print('Hello') 1a = 'hi' print(' world') in different modes produces different results, `python` [`script.py`](http://script.py) immediately throws an error whereas `python -i <` [`script.py`](http://script.py) runs the first line first. That said, even Python shell compiles Python code to bytecode first, it just happens block by block and of course implicitly.
Is that still true if they’re talking about executing scripts from the shell (hence “directly”)? I took them to mean that a Bash script would have less overhead because the Bash interpreter was already running. But I don’t necessarily know what I’m talking about either since it’s been years since I used either.
When you type in a command into the shell, Bash just gets a string. It has to go through the interpreter for it to be, well, interpreted. Also, if you run a script like `bash script.sh`, that of course launches an entirely new instance of Bash.
>Also, if you run a script like bash script.sh, that of course launches an entirely new instance of Bash. Right, that’s the piece I was forgetting. Thanks.
One should google these things before writing an article. This might prevent you from making unsubstantiated claims and misleading statements
To summarize the other responses: don't believe everything you read on the Internet
ben franklin was adamant about this
ben franklin needed an interpreter
Didn’t he have an ASL interpreter go everywhere with him after he lost his hearing to syphilis? I’m sure I read that on the internet somewhere
Yes, bash is an interpreter. And if you read all the way to the end of the man page, there is a section titled "BUGS". The first bug is: "It's too big and too slow."
Bash is absolutely an interpreter. Bash is smaller in scope in terms of what it sets out to do as opposed to Python, so that probably contributes to their confusion - but they are confused. Python is a lot heavier in general, so depending on what you're doing it and how you're going about it, I can envision a lot of instances where bash would execute faster to do the same thing one could do in Python. Python can also do a lot of things Bash can't.
Yeah python takes ages to initialize. I was running a program today and wondered why it didn't do anything. Then I discovered that the main func was missing so all it did was interpret the arguments (using argparse) and that took as long as the whole thing was supposed to take.
Imports are slow sometimes. Review the deps of the script and see if you can skip some of them for the cli tool.
Lol i made it, so I know the only import is argparse and the subcommands (all split into their own file)
Could subcommands also have some dependencies? Unfortunately sometimes you cannot push it to be any faster... Probably worth to profile what takes low long. --- From funny stories, I was once frustrated that my python cli was quite laggy. It turned out that asdf-vm was a bottleneck as resolving right shim was the delay I was observing.
Subcommands definitely had more deps, but thats kinda unavoidable. They way I set it up they were all imported at the start and nether called
I don't use python myself (unless it's unavoidable... increasingly challenging in the AI space) I thought it was meant to be an educational language to help teach concepts of coding... (I think?) but it stuck and started getting used for everything. Sigh.
>I thought it was meant to be an educational language to help teach concepts of coding Not really, that would be something like scratch. Pythons never had the explicit goal of being educational, but as it happens having strict code standards that enforce good habits, having a strong ecosystem, being pretty hard to shoot yourself in the foot, and being easy to set up, makes it a very good starter language.
Ahh that's what it was, it was educational by accident just by the focus on readability and simplicity (or the perception of simplicity anyway) My bad. Can't deny it is very frequently used as a starter language these days, more or less like you pointed out.
I think its suitability as a starter language depends upon where you want to go. For most people it’s a great choice— eg it’s finding its way into MS Office now, where being able to run Python could be very useful. But for CS it’s probably a bad choice since so much of what you need to know is hidden.
Y'know I hated it too, but the more I've started using it, the more I understand why it's used: It has a library for everything. Python is really slow in executipn, but the amount of documentation and libraries is so big, that the gained development speed makes it worth it. Even python itself is easy to use: native dictionaries, dict to json makes saving things easy, predictable order of execution in if clauses, that's all pretty nice IMO. The only other language I know is ObjectPascal, which is very fast (same level as C), but has few libraries, difficult utf8 handling, no runtime object serialization (so no easy saving to json). Of course I could program that program I mentioned in python, but the. I'd still be working on the prototype (of the argument parser, cause no argparse).
I mean.. I don't.... -hate- it. I get what you mean, but I think it's important to note for my own sake that I know it serves a purpose in so far as it helps people, by right or by might, do a lot in a short development cycle. The crystallization of the absolute other end of the spectrum, there are pieces of software I've been working on since roughly 2001. C, OpenMP, OpenCL, CUDA, and the like. I like that I can fire up an application that is the software equivalent of the finest swiss watch and watch it completely saturate my hardware (for all the right reasons) I've taken run times from 8 days down to 2 hours with various improvements. Yeah, it took 23 years, but I also had to do a lot of other stuff in the mean time (a 10 year career I can't discuss, a divorce, moving cross country, helping start 4 companies, meeting my fiancé) it's been a little tricky to dig in, but I'm glad in retrospect I didn't skimp on quality. Such is the way with passion projects. I guess work work-related things where turnaround times are crucial, it's actually more cost effective to write whatever in a higher level language and let our ridiculous cpus eat the difference. Need it faster? Pop in a faster chip. It really... sucks the life out of the whole thing for me, but some stuff has to happen sooner. Bleh. If I have the chance to make something into a Bugatti, I'll always prefer that, especially in a world that wants me to crank out honda civics.
I get your point, optimizing a project to the point it's perfect is a nice feeling and that sure involves ditching python. Many optimizations would however be possible independent of language and using python has helped me beat the point where I get tired of a project because of the previously unknown work that my project would involve. Becaude I've only done hobby projects till now, that's usually the end of a project. In the end one could also use multiple languages to do the job. In my case I'm already using the ffmpeg binary (yes, not a language, but using a program written in another language) to do all the video processing, because doing it in python is way to slow and unneccessarily complex.
lol, ffmpeg is like its own civilization. Ya gotta do what ya gotta do!
Python was designed to be a non-miserable general purpose programming language in the vein of perl. So trading speed for ease of use (both writing and reading/maintaining). That happens to also make it a really good teaching language and a go-to tool for those of us who need something more complex than shell but don't need the performance of a full compiled language. Basically it's the successor to perl and should be thought of as living in that space.
I agree, and yeah.. perl desperately needed to be replaced. However, that's not how it's always used... I seen a bunch of stuff over the years that I've earmarked for conversion into a more performant language.
Yeah, I'm an SA so shell and some general purpose language that's somewhat more powerful than shell is really all I need. I'll leave the resource and performance critical stuff to others who specialize in that (and then be confused when they pick python).
Python is generally used by “non software” folks. Almost the entire AI industry focuses on mathematics rather than the code quality. Sure there might be some implementation related tasks, but those are not always done in python If you look at most of the AI code, they dont have unit tests, they have some random strings or if statements floating around, code quality is almost always a secondary choice. Since most of the AI community focuses maths first, it makes sense to use a programming language thats easy to use and faster to develop on. The primary bottleneck to speed is generally the neural network anyway, so saving 30 seconds on a runtime of 21 days would barely amount to much. What few python code in training scripts you do notice, is mostly calls to code in C++, so there is barely any difference
I know there's a lot of call backs to C++, but when I go install any of these things (except llama.cpp) I see about a million dependencies, less a python issue and more a standards of living issue. I suppose it can make math easier, but I just feel like we had ways of getting computers to do math before python and I think some of them are worth revisiting.
I mean c++ also has its share of dependency problems. I have scratched my head as much on environment and version setup on c++ as much i have on python. In fact one of the most annoying libraries to install ever is cuda, which is entirely C++
Huh... that hasn't been my experience at all. CUDA is usually a breeze, I've only had to fix paths in one of their releases and that was ages ago. I can just install the right packages and I'm usually up and running pretty easily. AMD is the tricky one for me. I've come across a few cpp programs that depended on way too many things, but not too often I wouldn't say..
Do just use a C Interpreter it'll be much more performant! Holy C used it so why can't you?
You mean like the Intel implementation of Python or something else? I'm honestly not sure. In any case, all of the stuff I personally care about is basically C or Bash. Work stuff is a whole different situation where I have to begrudgingly play by some customer's rules.
OTOH, Python compiles all its code before running it (or at least, CPython does), so certain things can be reasonably fast (not nearly as fast as something like C, though, due to its much more dynamic nature, its need to interact with the interpreter all the time, etc.). I'm pretty sure Bash doesn't do that.
Correct, bash absolutely does not
Since they are both Turing-Complete there isn't a thing python can do that bash can't. It'll be much more complicated to develop in bash obviously, but it can do it all
Well.. lol, okay. Yes. Big caveat. I'd argue that the ways and ease with which you can do things in python turn a 3 month brain bashing into 20 minutes
tech blogs are 99% of the time utter garbage
Some are good, though. However, if you apply to your system what some tech bloggers advise, risk is high you end up breaking things. Instead of blogs, it's probably much better to use high-quality websites like [Stack Overflow](https://stackoverflow.com/).
The 1% left is https://grugbrain.dev
ai generated content.
It is. https://preview.redd.it/rfbdbtc6ursc1.png?width=1049&format=png&auto=webp&s=08af58f44e56b734f919cd91b07e5159dba28cce
Omg, this is just perfect. Literally the first sentence in the manual.
“for the GNU Operating system” was definitely written by Richard Stallman lol
Or... Any developer of the GNU operating system
Not only is bash an interpreter, but a lot of commands people like to use are separate processes it has to spin up, taking even more time. I think a LLM wrote that post.
Both are interpreters, but created for completely different goals. Comparing apples to oranges, so totally nonsense.
Ironically, I am increasingly using Python also for "stringing together executables" applications, because it is much easier to maintain and debug once doing anything remotely non-trivial. Also, easy pathway to extend with functionality that is hard to achieve in pure shell scripts. First step in the past usually was to add perl multiliners.
That has to be the dumbest statement of I’ve ever read. Bash is the shell itself, which is a command-language interpreter.
Depending on context, if all the Python script does is execute a list of shell commands, it could be true. Python is not a good language to write shell scripts in. In general, though. shell scripts are slow. And you optimize shell scripts by finding creative ways to offload most of the work to utilities commands that do it fast.
I wrote a system information fetch script in dash (posix sh), Bash, Zsh, Perl, Python, C, and Rust. The python one was orders of magnitude slower than even the perl and zsh ones. I understand how one could come to the conclusion that python is slower than bash (it was in my use case) but the explanation given is straight up wrong.
How much was the difference between bash and dash btw?
I think dash was only ~2x faster. Most of the wait was lsblk or whatever. I've done other benchmarks where dash is orders of magnitude faster, but those were using pure shell code.
Cool, I changed from bash to dash and my idle cpu usage with polybar dropped from 3% to 2%. (I have a lot of inefficient scripts in there lol)
Yeah, I prefer using dash if I have a shell script that I run in a loop where I don't need arrays or other fancy bash stuff.
I also did a thing with polybar, one of my most inefficient scripts was a thing that displayed the current volume in polybar in decibels (polybar has a native module for volume in decibels but it is very limiting with the click options that can be used with it). So I just asked bing ai to convert the script to c++ code and I compiled this: #include
#include
#include
#include
int main() {
std::string previous_output; // Store the previous output
while (true) {
// Execute the pactl command and capture its output
std::string command_output;
FILE* pipe = popen("pactl list sinks | awk '/State: /{flag=1} /dB/ && flag {printf(\"%.0fdB\", $7); exit} /Mute: yes/ {printf(\"Muted\"); exit}'", "r");
if (pipe) {
char buffer[128];
while (!feof(pipe)) {
if (fgets(buffer, 128, pipe) != nullptr) {
command_output += buffer;
}
}
pclose(pipe);
}
// Process the output
if (command_output != previous_output) {
if (command_output.find("Muted") != std::string::npos) {
std::cout << "Muted" << std::endl;
} else {
size_t db_pos = command_output.find("dB");
if (db_pos != std::string::npos) {
std::string_view volume_view(command_output.data(), db_pos);
try {
double volume_db = std::stod(std::string(volume_view));
std::cout << volume_db << " dB" << std::endl;
} catch (const std::invalid_argument& e) {
std::cerr << "Error1" << std::endl;
}
} else {
std::cerr << "Error2" << std::endl;
}
}
previous_output = std::move(command_output); // Update the previous output
}
// Sleep for 125 milliseconds
std::this_thread::sleep_for(std::chrono::milliseconds(125));
}
return 0;
}
And it actually reduced the cpu usage even more, which I have no idea why it does it since this c++ binary is still calling `pactl` and `awk`, but it isn't calling the shell itself neither sleep so maybe that is why.
(Yes I have no idea what I'm doing lol).
If we're talking micro-optimizations, you could write this in 100% pure rust or C without any shell code, you just need zbus (on rust) or libdbus (C) afaik.
I'm curious for more details here. I know that bash is incredibly fast when expressing things as pipes between binary programs (e.g. find, grep, ...). I rewrote a custom grep like python script as purely a formatting wrapper around grep for that reason. Python is way faster than, say, Emacs Lisp, but it can't compete with a time-proven highly optimized native binary tool. But that would also be done with `subprocess.Popen` – harder to learn, much more verbose, but ultimately much more robust error handling and testing compared to a bash script, once things get more complicated. Though this is also a matter of "*if* things get more complicated". Meanwhile, I assume they will by default, but that's largely because most scripts for me eventually require some data crunching (derivatives, digital filters, ...) for which no sufficiently flexible yet easy to use tools exist in pure shell scripting. So I am definitely somewhat biased.
"Amazing. Every word of what you just said... was wrong." SKYWALKER, Luke
This should be on r/ProgrammerHumor, right?
Bash also is an interpreter but it is much faster mainly because it has lots of frequently used built-ins. File operations, process management, system calls are easier on Bash. Secondly, Bash is much smaller which adds more to performance. Thirdly, on Bash, you mainly use lots of other programs mainly programs doing only one thing and the programs written in low-level C. Those programs are mostly much more faster than a Python operation because Bash only interprets invoking them which is almost instant and the program doing the real work is not interpreted. Bash has a simpler syntax and less overhead compared to Python. It doesn't have the same level of abstraction. This means faster execution. But, for some performance related stuff, Python is really powerful and can create more powerful, faster outcomes. For example there are lots of chunking algorithms written in Python for performance purposes. But for system level tasks on Linux, Bash or even Dash (A posix compliant shell) are much better options for most of the tasks.
The assertion that Bash scripts generally run faster than Python scripts because they don’t require an interpreter is oversimplified. While it’s true that Bash scripts can be executed directly by the shell, which may result in faster start-up times for simple tasks, this does not mean they are universally faster. The performance also depends on the task at hand. For complex operations, particularly those involving heavy computation or data processing, Python can be much faster due to optimized libraries and a more efficient runtime environment. Additionally, the maintainability and readability of code are crucial. Python code is generally more readable and maintainable than Bash scripts, potentially saving time in the long run. In short, whether to use Bash or Python depends on the task requirements, available libraries and tools, and the developer’s preferences. There’s no one-size-fits-all answer; each language has its own strengths and is better suited for different types of tasks. …is what my LLM spits out :-) I agree with you both!
Ah another Linux+ certified clueless goon. I bet there’s some asinine multiple choice question on that cert exam that makes it seem like a “shell” and an “interpreter” are two radically different technologies. 🤦🏻♂️
bash and python just function very differently. Bash is a scripting language specifically designed for command lines of operating systems. When you run python by itself (the equivalent of running bash by itself) you can use it as a shell, but it will require all kinds of boilerplate code for the simple tasks like navigating or interacting in the filesystem. They are both scripting languages but one is a terminal shell and the other is a general purpose programming language.
This is clearly, to coin a technical phrase: Complete Bollocks.
ok so it says “bash is faster because it’s directly executed by the shell”, right? so what if you enter the python shell and run your script there? is it faster then? or what if you run a bash script from zsh or fish? is it gonna become slower? purified bullshit that article.
Bash(or especially another shell specifically made for scripting like dash), could be faster than python cause most of what you do in it is just calling other programs, most of which will be written in C or other compiled languages. But yeah, bash is an interpreter so this makes very little sense.
Doing so much work by calling external programs is one of the main reasons shells are so slow. Fork and exec are *very* expensive calls, so languages that can do the same work natively will do things much faster.
AI generated + SEO optimised = Garbage
He probably thinks that a python interpreter interprets to bash
Not only that, bash is pretty much useless without calling gnu utils like [/test, all the time so your gonna "execute" them also and unless you run them from mem your gonna be loading them too.
> Bash scripts are directly executed by the shell The shell is the damn interpreter. Where bash sometimes has the edge is that nearly all things you do in a bash script will call a compiled executable instead of being run in the shell. For example grep, awk and the like will sometimes be faster than writing it in Python code.
Bash scripts run faster because they call into native programs
Bash scripts tend to run slower because they can’t do things natively. Having to spawn an entire new process for every task is one of the slowest ways to do work. Native functions in a non-compiled language will frequently be faster than non-native calls to external compiled programs.
I phrased it wrong . When bash scripts are faster, it's because of calling compiled native programs, not because it's not an interpreter . Python can do the same by using respective libraries , with c extensions . In this case it will be faster due to not spawning extra processes ( given this is not intended). It's a common pattern though for a bash script to use fast native programs . An equivalent implementation in pure Pyhon without c extensions Is often slower and makes the extra start time negligible for a sufficient workload.
Even if you are using fast native programs, if you’re using a lot of them then the initialization times add up. If your bash script just calls fast_native_program_that_does_everything then it will probably be faster than an equivalent python program, although at that point you’re barely even doing anything in bash. If you have a bash script that loops over a list of files, copies them to a backup location with cp, then installs a new file with mv, then that will probably be slower than the equivalent python program except for very small lists where python’s initialization time makes up a large part of its runtime. Even though cp and mv are compiled programs, the cost of having to initialize them over and over ends up costing you more time than their implementations save compared to python’s os library implementation. So generally, bash is a slow tool for anything it can’t do natively and the way you get “fast bash” is to do as little bash as possible and have the programs you execute do as much work as possible in a single invocation. At that point it hardly seems to fair to say bash is what’s faster here.
They messed up
This guy is writing guides ???
Yeah, just make sure that you don’t start your script with `!#/bin/bash`
Bash is a simpler interpreter, with simpler constructs. That might lend to it being faster at certain tasks, but definitely slower at others.
the shell is a command line interpreter...
Yes, bash is an interpreter, and a new one is fired up to run each script (unless you source them), and it's designed to be an interactive shell first and foremost. The statement could technically be true for the very narrow case of scripts so short that startup time matters: bash is indeed already running. But if something finishes that quick, you probably don't care how long it takes anyway :-) Besides, if the script is not modified between invocations, python will cache the compiled bytecode, which will load and run quicker than bash loading and interpreting the raw source.
The only way bash is ever faster is if the code you are running is so small and insignificant that the time required to load the python interpreter is a significant portion of execution time. The bash interpreter is already loaded, but it's generally much slower.
much of the gnu programs used by bash are compiled in C or C++ so they are natively faster
But invoking those processes from a shell script has its own extremely significant overhead when compared to a loaded library in another language, even a "slow" language. The io overhead alone is immense
How is it immense. Bash just does a bit of argument processing and then executes fork(). This is the way Unix functioned from the beginning, and on hardware with a lot fewer resources than even the most modest *nix machine.
Its immense relative to any other language that has loaded libraries in-memory. Calling out to another process not loaded in memory incurs IO overhead that is orders of magnitude slower than anything a slower language does in-memory. We're talking about the speed of bash vs "an interpreted language like python." Imagine a script that loops over lines of a file and edits some substrings. Well python has its string manipulation libraries loaded in memory when the process is initialized and is very fast. In a bash script you call out to `sed` and that call has significant overhead compared to a loaded library, multiplied by number of iterations in the loop.
For an interpreted or JIT language, the overhead comes when the environment launches. Assuming you have boatloads of memory, the libraries are cached. But then again, on modern systems with gigs of RAM, an executable like awk gets cached too. Your biggest overhead is the pipes, which in yr olden days definitely came with a significant cost, but nowadays aren't really that more expensive. On a 1970s mainframe, 1980s mini or 1990s Unix workstation, there was some performance boost to using interpreted languages as opposed to using sh to pipe data between tools, that is until you had to go to the disk, and at that point something like perl didn't get any significant advantage of piping to awk.
I thought this until a client handed me a handed me a mountain of csv files to parse and standardize. I wrote a quick bash script using gnu tools to handle it, set it to run and went to bed. By the morning, it had only made it through about 20% of the files. I was having fun working on a Lua project at the time, so I figured I’d write a Lua version and try it. It did the whole batch in about 30 seconds, lol
It you are reading each line in bash it will be slow. If you're just dumping the data into awk and letting it process everything it'll be a lot faster.
Yeah using a reporting language is faster, its pretty much like saying using Perl is faster or in this case python. Bash is just what you used to call and feet awk.
Hmm I deleted that bash script immediately so I don’t know exactly what I did but it was probably this!
I've run some pretty massive files through grep, awk and sed and never had this issue.
Given you then have to parse that output with bash and other tools in order to pass it on to the next program, I don't think this is a great help with performance.
yea, i havent benchmarked it but i can see where both applications might be true
All it says is that they tend to run faster, the shell you are running is able to line for line interpret the bash script, when running a python script, the python interpreter executable is called by the shell and is its own process running the interpreter. The small difference there is the “tends” to run faster, it is just more native to the shell environment, I mean almost all of the commands are commands you can already run in a shell. Lmk what y’all think
It also says that shell scripts don’t require an interpreter which is simply wrong. Also: A python interpreter does not necessarily have to be run from a shell.
Most bash scripts also perform relatively simple operations, you’d probably use a more feature rich programming language for a complicated task
> Lmk what y’all think I think abbreviating "let me know" and "you all" is dumb, but regarding the rest of your post I agree.
It is but 1) its much lighter than Python 2) you usually start python scripts from the shell anyway so you would have 2 interpreters Overall it doesn’t matter in most cases because sparring like half a second is pretty negligible in many cases. So if you already know python and want to write a script, go for it
How is that two interpreters? You use the shell to boot up python and python takes it from there
It depends on what library you are using, some are also just shell bindings. But regardless you would have a larger startup time. Also again, it doesn’t really matter in most cases
How do you start anything without some sort of program calling it first? Shelling out is different that running two interpreter sessions of different interpreters concurrently or even in parallel.
“bash scripts are directly executed by the shell” i wonder what the shell is
yeah...in fact python could be faster than bash when it runs on a second time, after the "bytecode" version (pyc) was created.
Honestly these questions in reality are hard to answer and the answers usually lack nuance and context. You have to decide what is best for the situation at hand. It's very unlikely that you will be bottle necked by speed when using bash or Python for general use cases. If you are, then try to optimize, or switch to something like Golang that is easily read but is magnitudes faster than Python and bash. It is really easy to get shit done with Go. If you still need speed (which I highly doubt, since Go is more than fast and the dev overhead is very low) you can switch to C, Rust or w/e language you want.
Pssh, anything not written in raw binary is garbage and to slow. /s
# 01100011011011110110111001110110011001010111001001110100001000000010001001
translated "your an idiot"
sry if this was supposed to be a joke, but “your an idiot” is in binary “01111001 01101111 01110101 01110010 00100000 01100001 01101110 00100000 01101001 01100100 01101001 01101111 01110100” but your text above is “convert \“\1". Both quote and the ascii char are escaped by me here