From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: 23 branch - can't push - lock Date: Fri, 17 Jun 2011 18:39:59 +0300 Message-ID: <83sjr8wjow.fsf@gnu.org> References: <1C745F22-51D9-4FE6-A8EF-5D621109E656@gmail.com> <83boxxy9de.fsf@gnu.org> <65EAEB6A-294A-4B8F-8BCA-F37C5914E5D6@gmail.com> <83aadhy1vg.fsf@gnu.org> <2B735F1F-756A-461D-A4D0-562AAC9BE17A@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1308330797 12797 80.91.229.12 (17 Jun 2011 17:13:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 17 Jun 2011 17:13:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 17 19:13:08 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QXcbT-0005a3-QK for ged-emacs-devel@m.gmane.org; Fri, 17 Jun 2011 19:13:08 +0200 Original-Received: from localhost ([::1]:39540 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXcbS-00053g-RS for ged-emacs-devel@m.gmane.org; Fri, 17 Jun 2011 13:13:06 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXbBQ-0004dQ-Cb for emacs-devel@gnu.org; Fri, 17 Jun 2011 11:42:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QXbBM-0007fj-VW for emacs-devel@gnu.org; Fri, 17 Jun 2011 11:42:07 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:44394) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QXbBM-0007fD-EM for emacs-devel@gnu.org; Fri, 17 Jun 2011 11:42:04 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LMX00C00XVO3T00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 17 Jun 2011 18:42:02 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.164.125]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LMX00BM7Y9YKWD0@a-mtaout22.012.net.il>; Fri, 17 Jun 2011 18:42:00 +0300 (IDT) In-reply-to: <2B735F1F-756A-461D-A4D0-562AAC9BE17A@gmail.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140617 Archived-At: > From: David Reitter > Date: Fri, 17 Jun 2011 09:57:43 -0400 > Cc: emacs-devel@gnu.org > > On Jun 16, 2011, at 4:09 PM, Eli Zaretskii wrote: > >> First page only: > >> real 0m3.594s [faster when repeated,i.e., in cache] > > > > What kind of machine is that? On my 6-year-old Windows box with a > > single 3 GHz core, I get this: > > Core i7, 2.6GHz, 4GB RAM. Strange. It should be faster than mine. > > And anyway, 3.5 sec is hardly significantly different from 0.8, for > > producing something that a human needs to _read_. > > Actually, I disagree. If you see 3.5 sec as a significant delay, I wonder what's your opinion about GCC compiling Emacs sources. And in case of "bzr log" the results need to be read by you, which will certainly take more than just 3 seconds. > A modern interface should not make the user wait that long - I would estimate anything beyond 30ms is discernible How do you mean "discernible"? Most humans are generally unable to react in less than 200-300ms, so 30ms is an order of magnitude off the mark. > and anything beyond 1s may be seen as interrupting someone's workflow. Typing a command takes more than 1s, so I guess your workflow is being interrupted all the time, and you are used to it anyway ;-) > At some point, people (perhaps including you) did an awesome job making Emacs start up fast. I only start my Emacs once in several weeks, so the startup (which is quite long, actually, because my sessions visit a lot of files) doesn't bother me more than the time it takes the entire machine to come up. > Just getting the first pages of a log should happen instantly Well, it takes less than 1s here, which is instant enough for me. > I'd find the timing you get acceptable, but mine is just sluggish. You should investigate the reasons for that sluggishness, then. > I started out with the wrong command, "bzr merge -c 104024", because I thought that the revision ID is unique (sorry, Git thinking). It took 65 seconds to give me an error message! How about submitting a bug report (https://bugs.launchpad.net/bzr) about that? > And the wording of the error message wasn't even very user-level: > > InvalidRevisionSpec: Requested revision: u'104024' does not exist in branch: BzrBranch7('file:///Users/dr/Projects/emacs/emacs-23/') Is that what was displayed on the screen, or is it from .bzr.log? The latter is not only for users, so I would tolerate some technicalities there for the sake of technical information the developers will want to know. > I updated Bazaar after that to 2.3.1, and did the same merge a second time (this one may be much easier for Bzr now - I don't know). > It still took 20 seconds. That's sluggish in my book. Most of my merges take less than 5 sec, but some took 20 or 30s. I don't consider that to be sluggish, but if you don't mind to live on the edge, try the latest beta of bzr 2.4, I understand that "merge" got a significant speedup there. > Is there a way to reset a branch to a previous commit, i.e., the equivalent of "git reset --hard"? That's git talk, and I don't really know what it means. If you want to be able to re-apply the same merge, I think you want "bzr uncommit". (But don't try that with a bound branch!) Alternatively, make a new branch from the revision before the merge, and then merge onto that.