Python 10s of multiples more CPU cycles than git. It is an interpreted language: every instruction is read by another process, checked, and then run. Hit on the other hand is executed straight by the CPU. It has at least one layer of indirection less than python (the python interpreter may have multiple). That means it can be slower but it definitely uses more energy.
Since git is so popular, if it were instead mercurial, the energy requirements would be much higher for version control. Whether that will be noticeable on a bill is debatable. I haven’t run the numbers.
Regarding the different python versions. As mentioned before, there is a python interpreter. That interpreter is versioned and so is the python language. Many things are backwards compatible meaning something written in a higher version of the python language can be interpreted by a lower version of the python interpreter. The reverse is also true, so python interpreter with a higher version can interpret a python file using a lower version of the language.
Notice that I put “can” in bold. That’s because newer versions can deprecate certain features or parts of the language. So, if you’re writing a project in a different version of python, mercurial may or may not run depending on your version. Resolving that may not be as intuitive as one thinks.
I think those were he points you were referring to when you asked your question?
I don’t think it’s hyperbole to say a significant percentage of Git activity happens on GitHub (and other “foundries”) – which are themselves a far cry from efficient.
My ultimate takeaway on the topic is that we’re stuck with Git’s very counterintuitive porcelain, and only satisfactory plumbing, regardless of performance/efficiency; but if Mercurial had won out, we’d still have its better interface (and IMO workflow), and any performance problems could’ve been addressed by a rewrite in C (or the Rust one that is so very slowly happening).
Python 10s of multiples more CPU cycles than git. It is an interpreted language: every instruction is read by another process, checked, and then run. Hit on the other hand is executed straight by the CPU. It has at least one layer of indirection less than python (the python interpreter may have multiple). That means it can be slower but it definitely uses more energy.
Since git is so popular, if it were instead mercurial, the energy requirements would be much higher for version control. Whether that will be noticeable on a bill is debatable. I haven’t run the numbers.
Regarding the different python versions. As mentioned before, there is a python interpreter. That interpreter is versioned and so is the python language. Many things are backwards compatible meaning something written in a higher version of the python language can be interpreted by a lower version of the python interpreter. The reverse is also true, so python interpreter with a higher version can interpret a python file using a lower version of the language.
Notice that I put “can” in bold. That’s because newer versions can deprecate certain features or parts of the language. So, if you’re writing a project in a different version of python, mercurial may or may not run depending on your version. Resolving that may not be as intuitive as one thinks.
I think those were he points you were referring to when you asked your question?
Anti Commercial-AI license
Surely it could be rewritten in Fortran if performance is really a concern.
Assembly is the true language of the gods, sir.
Anti Commercial-AI license
Apart from the obvious lack of portability, compilers write better assembly than most humans.
I don’t think it’s hyperbole to say a significant percentage of Git activity happens on GitHub (and other “foundries”) – which are themselves a far cry from efficient.
My ultimate takeaway on the topic is that we’re stuck with Git’s very counterintuitive porcelain, and only satisfactory plumbing, regardless of performance/efficiency; but if Mercurial had won out, we’d still have its better interface (and IMO workflow), and any performance problems could’ve been addressed by a rewrite in C (or the Rust one that is so very slowly happening).
Imagine if their VCS operations were 10s of times less efficient 😉
Anti Commercial-AI license
Most of the VCS ops in Hg are actually written in C.
GitHub is mostly written in Ruby, so that’s not really a performance win.
Like I said, we’re stuck with Git’s UX, but we were never stuck with Hg’s performance.