Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Git won because it's superior in a way that many programmers think doesn't matter: performance.

Git is incredibly fast. Many operations happen almost instantaneously even on large repositories. It's really nice. I've heard a lot of people talk about how they abandoned mercurial because it's slow. Some even switched to git from svn not because git's model is better but because svn is slower.

"Premature optimization is the root of all evil" is an old programming advice quote that is so horribly misunderstood that it's basically wrong. It means think about your problem at the high (algorithm and overall goal / design space) level before worrying about low-level optimizations. It does not mean that optimization is bad or that performance isn't important.

I made another comment recently on the same issue. I really wish that quote would die in favor of more substantial advice that won't be so misunderstood.



Are you working on a Linux system? I have the opposite experience with Sourcetree and Gitkraken on Windows -- git is the least responsive tool I use.


Git is the only fast tool in that stack, it's slow because of the trinity of ntfs, electron and c# that those tools are built with. When you've got slow tools on a slow file system you're going to have a slow time.


If performance mattered, people would not have adapted electron


"Premature optimization is the root of all evil" means: make it work correctly first, and then - if anybody cares - make it fast. Readability/maintainability, then only as needed trade it off for speed, because not all code needs to be highly performant.


Mercurial works correctly but is unbelievably slow compared to git.

If you don't think about performance ahead of time (preferably at the algorithm level) then you will build something correct but slow and it'll be very hard to make it fast without redesigning major parts of it. It's possible to make design choices that paint you into a performance corner very easily, especially with something designed to work on a lot of data. O(n^2) might look like O(log n) for small data and in testing.


From the Knuth paper:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

It means make it fast in the code that matters, do not try to make it fast in every single line.

To say the quote is often misunderstood is the biggest understatement in modern computer science.


I think any good advice in software development will be widely misunderstood. At lest, I haven't seen any that wasn't.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: