From: Lennart Borgman <lennart.borgman@gmail.com>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: emacs-devel@gnu.org
Subject: Re: Surely 'bzr update' shouldn't be this slow?
Date: Thu, 7 Jan 2010 15:03:05 +0100 [thread overview]
Message-ID: <e01d8a51001070603i7036c004vb6dbed11fc20ab6a@mail.gmail.com> (raw)
In-Reply-To: <87wrzuc93h.fsf@telefonica.net>
On Thu, Jan 7, 2010 at 2:56 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Sometimes I work on a netbook, which maybe is comparable to your 1.2GHz
> Athlon on CPU power, and some operations are slow indeed (>20 seconds
> for the log of a file.) I raised this on the Bazaar ml, but most people
> there think that Bazaar is fast enough and no extensive work is planned
> for performance improvements.
If that is the case I really wonder what is wrong. We use to complain
that software from MS needs faster and faster machines.
It should of course not be like that for free software. It should not
pollute. It should not stop people who can't afford faster machines.
next prev parent reply other threads:[~2010-01-07 14:03 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-03 17:47 Surely 'bzr branch' shouldn't be this slow? Alan Mackenzie
2010-01-03 17:59 ` Óscar Fuentes
2010-01-06 13:10 ` Alan Mackenzie
2010-01-06 13:28 ` Jason Rumney
2010-01-06 14:06 ` Óscar Fuentes
2010-01-06 18:23 ` Eli Zaretskii
2010-01-06 20:21 ` Stefan Monnier
2010-01-07 7:44 ` Yavor Doganov
2010-01-07 8:37 ` Lennart Borgman
2010-01-07 9:31 ` Juanma Barranquero
2010-01-07 19:18 ` Stephen Berman
2010-01-07 19:54 ` Eli Zaretskii
2010-01-07 20:09 ` Lennart Borgman
2010-01-07 21:48 ` Jason Earl
2010-01-07 23:48 ` Lennart Borgman
2010-01-08 2:07 ` Jason Earl
2010-01-08 7:10 ` Lennart Borgman
2010-01-08 8:13 ` Eli Zaretskii
2010-01-07 14:46 ` Stefan Monnier
2010-01-07 17:05 ` Yavor Doganov
2010-01-07 19:43 ` Stefan Monnier
2010-01-07 19:46 ` Lennart Borgman
2010-01-07 20:26 ` Thrashing [was: Surely 'bzr branch' shouldn't be this slow?] Stephen J. Turnbull
2010-01-07 20:20 ` Lennart Borgman
2010-01-07 13:40 ` Surely 'bzr update' shouldn't be this slow? [was: branch] Alan Mackenzie
2010-01-07 13:56 ` Surely 'bzr update' shouldn't be this slow? Óscar Fuentes
2010-01-07 14:03 ` Lennart Borgman [this message]
2010-01-07 15:18 ` Jan Djärv
2010-01-07 14:52 ` Alan Mackenzie
2010-01-07 15:00 ` Juanma Barranquero
2010-01-07 15:17 ` Karl Fogel
2010-01-07 17:51 ` Glenn Morris
2010-01-07 20:48 ` Karl Fogel
2010-01-07 21:21 ` Glenn Morris
2010-01-08 8:48 ` Eli Zaretskii
2010-01-07 15:17 ` Óscar Fuentes
2010-01-07 17:54 ` Stephen J. Turnbull
2010-01-07 15:06 ` Stefan Monnier
2010-01-06 14:37 ` Surely 'bzr branch' " Stefan Monnier
2010-01-07 5:00 ` Karl Fogel
-- strict thread matches above, loose matches on Subject: below --
2010-01-07 23:29 Surely 'bzr update' " grischka
2010-01-08 5:57 ` Stephen J. Turnbull
2010-01-08 17:49 ` grischka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e01d8a51001070603i7036c004vb6dbed11fc20ab6a@mail.gmail.com \
--to=lennart.borgman@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).