5 ms·

$ hg clone https://bitbucket.org/eigen/eigen/ $ cd eigen $ time hg grep CUDA > /dev/null real 0m16.661s user 0m16.097s sys 0m0.531s $ git clone htt

by jlebar 10y ago

$ hg clone https://bitbucket.org/eigen/eigen/ $ cd eigen $ time hg grep CUDA > /dev/null real 0m16.661s user 0m16.097s sys 0m0.531s $ git clone https://github.com/RLovelett/eigen.git $ cd eigen $ time git grep CUDA > /dev/null real 0m0.019s user 0m0.035s sys 0m0.057s Never looked back.

BeetleB 10y ago
This is also why I prefer using C over Python. (End Sarcasm). Seriously? You're so productive that the cost of cloning a repository is a major impediment? The benefits of a cleaner interface mostly trump the benefits of speed.
- jlebar 10y ago
  > Seriously? You're so productive that the cost of cloning a repository is a major impediment? Read the commands more carefully. It is not the cost of cloning the repository, but rather the cost of searching it.
  - BeetleB 10y ago
    Ah. My mistake. 16s is not a big deal, but I'm assuming it would get much worse for larger repositories. Personally, my searches are either: 1. Restricted to all files that end in cpp, h, py, pl, etc. 2. Explicitly exclude .hg directories. I'll confess: I use a nice tool to do my searches than typing it out in grep. Much handier. And it remembers previously used filters (.cpp,.h) and is usually the first item in the drop down box. Much quicker than typing out a grep command. Still, I feel if our team used git instead of hg, we'd lose a lot more time due to people not grokking git and making mistakes than the time lost in longer searches. My point still stands: Things like search time are not a productivity bottleneck. If all our searches were 100x faster, there would be no difference in our output.
    - Jtsummers 10y ago
      16 seconds versus a fraction of a second. There's a big difference, somewhere, in what these two systems are doing to accomplish (ostensibly) the same task. And if it's not accomplishing the same task, they shouldn't be using the same verb (grep) for it. And I disagree with this point: Things like search time are *not* a productivity bottleneck. I maintain old codebases. I don't know them by heart, I didn't write them and the documentation is often poor (for the codebase, the specs are usually decent, but that's the system spec, not the code spec). Search is critical for me to get around these things. A 16s search would be incredibly annoying and bottlenecking compared to one that's nearly instant. Not having looked at the internals of either, I wonder if this is related to other performance differences in grep implementations across *nix systems. EDIT: Exploring this, it seems they don't do the same thing? `git grep` searches, by default, only the most recent working tree or revision. It doesn't search every revision unless you tell it to. `hg grep` (don't have it installed) seems to search every revision by default, so restricting it to the current revision requires an explicit command line option specifying the revision range to search.
    - jlebar 10y ago
      Things like search time are *not* a productivity bottleneck. I would recommend, as a general rule, not generalizing from your development experience to everyone's development experiences. I happen to know that git grep is very carefully optimized. Someone cared a lot about making it run fast. Seems like a good guess that they did so because it was important to them or someone else, not just for funzies. $ grep '^git grep' ~/.bash_history | wc -l 407 $ grep -w '^ls' ~/.bash_history | wc -l 37 $ wc -l ~/.bash_history 19421 "git grep" is 2% of all the commands I type. I type it 10x as often as "ls". So, yeah, its speed matters to me. :)
      - ubernostrum 10y ago
        I would recommend, as a general rule, not generalizing from your development experience to everyone's development experiences. What's interesting here is that it's the exact thing happening. Someone asked about how much hidden cost there is from the time people waste fighting to make git do what they need it to do, and it got derailed with a discussion of how `git grep` is faster than `hg` grep`. I'm sure it's great for you that git's grep is fast. But the time you gain from how much faster it is than hg probably is strongly outweighed by the time other people lose to struggling with git's interface. Unfortunately there's no easy way to benchmark that.
witty_username 10y ago
Did you run hg grep once before to keep it in the disk cache?
- mjevans 10y ago
  I think the implication is that the freshly checked out state of the files was used. I do agree that reproducible differences in performance should be measured, not single tests.
- jlebar 10y ago
  It seems I cannot post a performance comparison without people asking about disk caches. :) First of all, if I just cloned the repos, they should be in disk cache. My machine has 64GB of RAM. Second of all, if they're not in disk cache, what on earth is hg doing that it takes 16 seconds to read them all in? Eigen is not that big, and I have a fast SSD. Third of all, you can run the tests yourself -- I gave you the exact commands to try. "I tried it and my results are X" is a much better contribution to the discussion. Fourth of all, yes, I ran the benchmarks multiple times in a row to check whether disk cache was at play. It was not. :)
  - witty_username 10y ago
    > It seems I cannot post a performance comparison without people asking about disk caches. :) Sorry, the speedup was very great so it almost seemed like something else was causing it. Thanks for the benchmarks. > Third of all, you can run the tests yourself -- I gave you the exact commands to try. "I tried it and my results are X" is a much better contribution to the discussion. That's true; I'm lazy. Actually, I was thinking more of the disk cache of loading hg, not the repo (Python programs tend to have a great speedup through the disk cache).
duaneb 10y ago
Well, you can just use the silver searcher with both. This is not a great argument for a better DVCS.
jlebar 10y ago
As Jtsummers pointed out downthread, hg grep searches all revisions by default. No wonder it's so slow. $ time hg grep --rev tip CUDA > /dev/null real 0m0.075s user 0m0.055s sys 0m0.020s Much better. Still much slower than git, which doesn't matter for this small repo but would definitely matter on a larger repo. But better. And hg lets you define aliases, so you don't have to remember to type "--rev tip".
Hello71 10y ago
this is a highly misleading comparison. something slightly more accurate (although this time somewhat more hg-biased): $ time taskset -c 2 hg grep CUDA >/dev/null taskset -c 2 hg grep CUDA > /dev/null 25.04s user 0.46s system 99% cpu 25.514 total $ time taskset -c 2 sh -c 'git grep --cached -l CUDA | xargs -n 1 git blame >/dev/null' taskset -c 2 sh -c 4.85s user 0.13s system 97% cpu 5.097 total
- jlebar 10y ago
  > this is a highly misleading comparison. Why? When I do hg grep, it doesn't show me blame or anything; the output looks almost identical to the output of git grep. If it's doing work and then throwing it away, why is it fair to force git to do the same work and then also throw it away? (I'll also point out that git is still 5x faster in this comparison. :)
hobarrera 10y ago
The biggest differences for me are: * Network effect. Almost any dev can use git, so it's our "common language". * Staging area. Mercurial doesn't have one, which I find is enough to make me never look back.

by jlebar 10y ago

BeetleB 10y ago

This is also why I prefer using C over Python. (End Sarcasm). Seriously? You're so productive that the cost of cloning a repository is a major impediment? The benefits of a cleaner interface mostly trump the benefits of speed.

jlebar 10y ago
> Seriously? You're so productive that the cost of cloning a repository is a major impediment? Read the commands more carefully. It is not the cost of cloning the repository, but rather the cost of searching it.
- BeetleB 10y ago
  Ah. My mistake. 16s is not a big deal, but I'm assuming it would get much worse for larger repositories. Personally, my searches are either: 1. Restricted to all files that end in cpp, h, py, pl, etc. 2. Explicitly exclude .hg directories. I'll confess: I use a nice tool to do my searches than typing it out in grep. Much handier. And it remembers previously used filters (.cpp,.h) and is usually the first item in the drop down box. Much quicker than typing out a grep command. Still, I feel if our team used git instead of hg, we'd lose a lot more time due to people not grokking git and making mistakes than the time lost in longer searches. My point still stands: Things like search time are not a productivity bottleneck. If all our searches were 100x faster, there would be no difference in our output.
  - Jtsummers 10y ago
    16 seconds versus a fraction of a second. There's a big difference, somewhere, in what these two systems are doing to accomplish (ostensibly) the same task. And if it's not accomplishing the same task, they shouldn't be using the same verb (grep) for it. And I disagree with this point: Things like search time are *not* a productivity bottleneck. I maintain old codebases. I don't know them by heart, I didn't write them and the documentation is often poor (for the codebase, the specs are usually decent, but that's the system spec, not the code spec). Search is critical for me to get around these things. A 16s search would be incredibly annoying and bottlenecking compared to one that's nearly instant. Not having looked at the internals of either, I wonder if this is related to other performance differences in grep implementations across *nix systems. EDIT: Exploring this, it seems they don't do the same thing? `git grep` searches, by default, only the most recent working tree or revision. It doesn't search every revision unless you tell it to. `hg grep` (don't have it installed) seems to search every revision by default, so restricting it to the current revision requires an explicit command line option specifying the revision range to search.
  - jlebar 10y ago
    Things like search time are *not* a productivity bottleneck. I would recommend, as a general rule, not generalizing from your development experience to everyone's development experiences. I happen to know that git grep is very carefully optimized. Someone cared a lot about making it run fast. Seems like a good guess that they did so because it was important to them or someone else, not just for funzies. $ grep '^git grep' ~/.bash_history | wc -l 407 $ grep -w '^ls' ~/.bash_history | wc -l 37 $ wc -l ~/.bash_history 19421 "git grep" is 2% of all the commands I type. I type it 10x as often as "ls". So, yeah, its speed matters to me. :)
    - ubernostrum 10y ago
      I would recommend, as a general rule, not generalizing from your development experience to everyone's development experiences. What's interesting here is that it's the exact thing happening. Someone asked about how much hidden cost there is from the time people waste fighting to make git do what they need it to do, and it got derailed with a discussion of how `git grep` is faster than `hg` grep`. I'm sure it's great for you that git's grep is fast. But the time you gain from how much faster it is than hg probably is strongly outweighed by the time other people lose to struggling with git's interface. Unfortunately there's no easy way to benchmark that.

witty_username 10y ago

Did you run hg grep once before to keep it in the disk cache?

mjevans 10y ago
I think the implication is that the freshly checked out state of the files was used. I do agree that reproducible differences in performance should be measured, not single tests.
jlebar 10y ago
It seems I cannot post a performance comparison without people asking about disk caches. :) First of all, if I just cloned the repos, they should be in disk cache. My machine has 64GB of RAM. Second of all, if they're not in disk cache, what on earth is hg doing that it takes 16 seconds to read them all in? Eigen is not that big, and I have a fast SSD. Third of all, you can run the tests yourself -- I gave you the exact commands to try. "I tried it and my results are X" is a much better contribution to the discussion. Fourth of all, yes, I ran the benchmarks multiple times in a row to check whether disk cache was at play. It was not. :)
- witty_username 10y ago
  > It seems I cannot post a performance comparison without people asking about disk caches. :) Sorry, the speedup was very great so it almost seemed like something else was causing it. Thanks for the benchmarks. > Third of all, you can run the tests yourself -- I gave you the exact commands to try. "I tried it and my results are X" is a much better contribution to the discussion. That's true; I'm lazy. Actually, I was thinking more of the disk cache of loading hg, not the repo (Python programs tend to have a great speedup through the disk cache).

duaneb 10y ago

Well, you can just use the silver searcher with both. This is not a great argument for a better DVCS.

jlebar 10y ago

As Jtsummers pointed out downthread, hg grep searches all revisions by default. No wonder it's so slow. $ time hg grep --rev tip CUDA > /dev/null real 0m0.075s user 0m0.055s sys 0m0.020s Much better. Still much slower than git, which doesn't matter for this small repo but would definitely matter on a larger repo. But better. And hg lets you define aliases, so you don't have to remember to type "--rev tip".

Hello71 10y ago

this is a highly misleading comparison. something slightly more accurate (although this time somewhat more hg-biased): $ time taskset -c 2 hg grep CUDA >/dev/null taskset -c 2 hg grep CUDA > /dev/null 25.04s user 0.46s system 99% cpu 25.514 total $ time taskset -c 2 sh -c 'git grep --cached -l CUDA | xargs -n 1 git blame >/dev/null' taskset -c 2 sh -c 4.85s user 0.13s system 97% cpu 5.097 total

jlebar 10y ago
> this is a highly misleading comparison. Why? When I do hg grep, it doesn't show me blame or anything; the output looks almost identical to the output of git grep. If it's doing work and then throwing it away, why is it fair to force git to do the same work and then also throw it away? (I'll also point out that git is still 5x faster in this comparison. :)

hobarrera 10y ago

The biggest differences for me are: * Network effect. Almost any dev can use git, so it's our "common language". * Staging area. Mercurial doesn't have one, which I find is enough to make me never look back.