3 ms·

> When I tried using it, it was painfully slow, taking 20-30 seconds for a simple 'bzr log'. When did you use it? On what history size? bzr 2.x series is quite

by prog 17y ago

> When I tried using it, it was painfully slow, taking 20-30 seconds for a simple 'bzr log'. When did you use it? On what history size? bzr 2.x series is quite fast.

dlsspy 17y ago
Here's the difference between bzr log on my clone of emacs: 23.040u 1.518s 0:25.31 96.9% 0+0k 0+73io 0pf+0w git log on my clone of emacs: 2.197u 0.226s 0:02.89 83.3% 0+0k 36+14io 0pf+0w
- prog 17y ago
  What was the version of bzr and git? Was this windows or unix? I suspect its unix only. It would be good to see the numbers on both platforms. Is this a limited rev history or the entire history? You also don't mentioned the exact commands you run. Do you use n=0 or n=1 with bzr? I would normally use n=1 as n=1 is not of much interest. Such limited microbenchmarks merely spread FUD. Also, while choosing a DVCS, the common operations have to be fast not all operations. So the interesting benchmark would provide numbers for all the common operation. Just running one operation can be misleading. I do much more with my DVCS than just run the log operation :-) Also, I don't see myself doing a log of a full 20+ year history multiple times during the day (In fact I have never done that). The commands I use normally, are fast enough large repos with bzr (emacs included).
  - dlsspy 17y ago
    You know, I had bzr 1.17 or similar. I upgraded to 2.1 and got the same time (slightly over 25 seconds). git version is 1.7.0.3. Both on my mac (I don't do Windows). In both cases, it was whatever "<cmd> clone <url>" does by default. So pretty much, all defaults all around. I mentioned this because someone else was saying it was as fast. I don't know anything about the n= things... I just ran "bzr log > /dev/null" and "git log > /dev/null" (my shell automatically times all commands). I tend to use and search logs a lot in my projects. With 2s to generate a log output, you won't think about the cost of looking through the whole thing for something (I did similar in an active hg project earlier today). I do get your point. It's not a... holistic benchmark. In another thread, someone called fowl on the article discussing size vs. bytes transferred. I thought it'd be better to think of that as time. Cloning roughly the same content via bzr and git (memcached master branch -- which is cloned at lp and contains just about the same history, though is somehow smaller at lp) takes a bit over 20 seconds and a bit under 4 seconds respectively. I suppose it's valid to argue that you don't clone much, either. At some point, one would wonder whether you avoid certain things because they're slow.

by prog 17y ago

> When I tried using it, it was painfully slow, taking 20-30 seconds for a simple 'bzr log'. When did you use it? On what history size? bzr 2.x series is quite fast.

dlsspy 17y ago

Here's the difference between bzr log on my clone of emacs: 23.040u 1.518s 0:25.31 96.9% 0+0k 0+73io 0pf+0w git log on my clone of emacs: 2.197u 0.226s 0:02.89 83.3% 0+0k 36+14io 0pf+0w

prog 17y ago
What was the version of bzr and git? Was this windows or unix? I suspect its unix only. It would be good to see the numbers on both platforms. Is this a limited rev history or the entire history? You also don't mentioned the exact commands you run. Do you use n=0 or n=1 with bzr? I would normally use n=1 as n=1 is not of much interest. Such limited microbenchmarks merely spread FUD. Also, while choosing a DVCS, the common operations have to be fast not all operations. So the interesting benchmark would provide numbers for all the common operation. Just running one operation can be misleading. I do much more with my DVCS than just run the log operation :-) Also, I don't see myself doing a log of a full 20+ year history multiple times during the day (In fact I have never done that). The commands I use normally, are fast enough large repos with bzr (emacs included).
- dlsspy 17y ago
  You know, I had bzr 1.17 or similar. I upgraded to 2.1 and got the same time (slightly over 25 seconds). git version is 1.7.0.3. Both on my mac (I don't do Windows). In both cases, it was whatever "<cmd> clone <url>" does by default. So pretty much, all defaults all around. I mentioned this because someone else was saying it was as fast. I don't know anything about the n= things... I just ran "bzr log > /dev/null" and "git log > /dev/null" (my shell automatically times all commands). I tend to use and search logs a lot in my projects. With 2s to generate a log output, you won't think about the cost of looking through the whole thing for something (I did similar in an active hg project earlier today). I do get your point. It's not a... holistic benchmark. In another thread, someone called fowl on the article discussing size vs. bytes transferred. I thought it'd be better to think of that as time. Cloning roughly the same content via bzr and git (memcached master branch -- which is cloned at lp and contains just about the same history, though is somehow smaller at lp) takes a bit over 20 seconds and a bit under 4 seconds respectively. I suppose it's valid to argue that you don't clone much, either. At some point, one would wonder whether you avoid certain things because they're slow.