Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 09BE4431FBC for ; Thu, 10 Dec 2009 22:10:23 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeSAZtSmRxw5 for ; Thu, 10 Dec 2009 22:10:22 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by olra.theworths.org (Postfix) with ESMTP id 69006431FAE for ; Thu, 10 Dec 2009 22:10:22 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by mx.perfora.net (node=mxus2) with ESMTP (Nemesis) id 0MbvmY-1Nc9z12uYw-00JHFz for notmuch@notmuchmail.org; Fri, 11 Dec 2009 01:10:21 -0500 Received: from www.hohndel.org ([65.23.156.142] helo=[127.0.0.3]) by bombadil.infradead.org with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1NIyho-0005UI-Nk for notmuch@notmuchmail.org; Fri, 11 Dec 2009 06:10:21 +0000 From: Dirk Hohndel To: notmuch@notmuchmail.org Content-Type: text/plain; charset="UTF-8" Organization: Intel Open Source Technology Center Date: Thu, 10 Dec 2009 22:10:13 -0800 Message-Id: <1260511813.3341.22.camel@dhohndel-mobl.amr.corp.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 (2.28.0-2.fc12) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Subject: [notmuch] emacs mode performance issue X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 06:10:23 -0000 I'm in the search results window in Emacs, on an LKML thread with 140+ messages. I hit return to view this thread - Emacs consumes 100% CPU but even after waiting 3 minutes it doesn't display the result (this is on a fast system Lenovo x200s). C-g stops the process and gets me dumped into a clearly partially processed buffer. Is there a good way to collect more profiling information to figure out why this is so slow? /D -- Dirk Hohndel Intel Open Source Technology Center