[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Abolishing ChangeLog files
From: |
Eli Zaretskii |
Subject: |
Re: Abolishing ChangeLog files |
Date: |
Thu, 28 Mar 2013 23:29:53 +0200 |
> Date: Fri, 29 Mar 2013 01:04:35 +0400
> From: Dmitry Gutov <address@hidden>
> Cc: address@hidden, address@hidden
>
> To answer your question, then, yes, 4.5 times faster indeed is "much
> more quickly". The difference here is not critical, but nice to have.
Get real! This started from the example of someone looking at the log
entry; human needs much more than a few hundreds of milliseconds to
read it, so a difference of 700 msec (for 5000 revisions!) is entirely
irrelevant. Do you really know someone who can read 5000 entries in
under one second?
> >> In my experience, Bzr is especially slow when showing log for a subtree
> >> or a specific file.
> >
> > I could ask you to show numbers (because I have no such experience),
> > but I won't. No one in this thread wants any serious discussion,
> > anyway.
>
> I would send you the numbers if you pointed me at the mingw port of
> 'time' you're apparently using.
I wrote that program myself. Unix 'time' cannot be ported, because it
uses too many Posix APIs.
> But here's an example command:
>
> git log lisp\progmodes\ruby-mode.el | less
>
> It takes about 300ms on the first run and is instantaneous after that.
Not here:
$ time git log lisp/progmodes/ruby-mode.el > /dev/null
real 0m5.140s
user 0m0.015s
sys 0m0.000s
D:\gnu\bzr\emacs\msys-build>timep bzr log lisp\progmodes\ruby-mode.el > nul
real 00h00m04.281s
user 00h00m04.078s
sys 00h00m00.218s
Entirely comparable. And re-running the commands doesn't change the
times, so I don't think any caching is involved.
> Anyway, the most important speedup I expect to see is the time it takes
> to do "git pull" vs "bzr update". I haven't done any real testing there
> yet, but the latter command takes entirely too long.
Depends on how large is your pull. E.g., the initial "git clone" took
me almost 3 hours; bzr did the same in under 50 min.
But we have been all through this, time and again. The real numbers
don't convince anyone. It's a religious argument since day one.
- Re: Abolishing ChangeLog files, (continued)
- Re: Abolishing ChangeLog files, Steve Youngs, 2013/03/28
- Re: Abolishing ChangeLog files, Thierry Volpiatto, 2013/03/28
- Re: Abolishing ChangeLog files, John Wiegley, 2013/03/28
- Re: Abolishing ChangeLog files, Steve Youngs, 2013/03/28
- Re: Abolishing ChangeLog files, Stefan Monnier, 2013/03/28
- Re: Abolishing ChangeLog files, Eli Zaretskii, 2013/03/28
- Re: Abolishing ChangeLog files, Eli Zaretskii, 2013/03/28
- Re: Abolishing ChangeLog files, Dmitry Gutov, 2013/03/28
- Re: Abolishing ChangeLog files, Eli Zaretskii, 2013/03/28
- Re: Abolishing ChangeLog files, Dmitry Gutov, 2013/03/28
- Re: Abolishing ChangeLog files,
Eli Zaretskii <=
- Re: Abolishing ChangeLog files, Dmitry Gutov, 2013/03/28
- Re: Abolishing ChangeLog files, Eli Zaretskii, 2013/03/29
- Re: Abolishing ChangeLog files, Eli Zaretskii, 2013/03/29
- Re: Abolishing ChangeLog files, Thierry Volpiatto, 2013/03/29
- Re: Abolishing ChangeLog files, Eli Zaretskii, 2013/03/29
- Re: Abolishing ChangeLog files, Stephen J. Turnbull, 2013/03/29
- Re: Abolishing ChangeLog files, Eli Zaretskii, 2013/03/29
- Re: Abolishing ChangeLog files, Stephen J. Turnbull, 2013/03/29
- Re: Abolishing ChangeLog files, Eli Zaretskii, 2013/03/29
- Re: Abolishing ChangeLog files, Thierry Volpiatto, 2013/03/29