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: ntemacs hangs when openning the attached file Date: Wed, 07 May 2008 11:48:47 +0300 Message-ID: References: <42b562540805062101s3e79eecel5ddc5b19821deda2@mail.gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1210150401 31864 80.91.229.12 (7 May 2008 08:53:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 May 2008 08:53:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: yu jie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 07 10:53:56 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JtfPD-0002H3-65 for ged-emacs-devel@m.gmane.org; Wed, 07 May 2008 10:53:43 +0200 Original-Received: from localhost ([127.0.0.1]:43445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JtfOV-0007vD-H9 for ged-emacs-devel@m.gmane.org; Wed, 07 May 2008 04:52:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JtfKX-0005CF-Cj for emacs-devel@gnu.org; Wed, 07 May 2008 04:48:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JtfKT-00059K-VM for emacs-devel@gnu.org; Wed, 07 May 2008 04:48:52 -0400 Original-Received: from [199.232.76.173] (port=59739 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JtfKT-000599-QX for emacs-devel@gnu.org; Wed, 07 May 2008 04:48:49 -0400 Original-Received: from mtaout2.012.net.il ([84.95.2.4]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JtfKT-0008SV-6B for emacs-devel@gnu.org; Wed, 07 May 2008 04:48:49 -0400 Original-Received: from HOME-C4E4A596F7 ([83.130.255.47]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K0H00DZ6QHD10E1@i_mtaout2.012.net.il> for emacs-devel@gnu.org; Wed, 07 May 2008 12:03:13 +0300 (IDT) In-reply-to: <42b562540805062101s3e79eecel5ddc5b19821deda2@mail.gmail.com> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 9.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:96668 Archived-At: > Date: Wed, 7 May 2008 12:01:38 +0800 > From: "yu jie" > > The current CVS header version hangs when openning the attached file. No, it doesn't hang, it just takes a lot of time to visit this file. I measured 61 seconds on a 3GHz machine. This file has 86406 lines, and uses some pretty non-standard formatting, such as this one: static int simpleNext( sqlite3_tokenizer_cursor *pCursor, /* Cursor returned by simpleOpen */ const char **ppToken, /* OUT: *ppToken is the token text */ int *pnBytes, /* OUT: Number of bytes in token */ int *piStartOffset, /* OUT: Starting offset of token */ int *piEndOffset, /* OUT: Ending offset of token */ int *piPosition /* OUT: Position integer of token */ ){ It also uses long comments formatted like this: /* ** Additional bit values that can be ORed with an affinity without ** changing the affinity. */ I'm guessing that this formatting coupled with the sheer size of the file somehow triggers an inefficiency. I didn't dig into the problem deep enough to find the actual culprit, but if I run Emacs under GDB and interrupt it during the long wait, I always see the following Lisp backtrace: "parse-partial-sexp" (0x82e9c4) "c-literal-limits" (0x82eb14) "c-neutralize-syntax-in-CPP" (0x82ec64) "c-common-init" (0x82edb4) "c-mode" (0x82eef4) "set-auto-mode-0" (0x82f034) "set-auto-mode" (0x82f110) "normal-mode" (0x82f454) "after-find-file" (0x82f5a4) "find-file-noselect-1" (0x82f6e4) "find-file-noselect" (0x82f834) "find-file" (0x82f984) "call-interactively" (0x82fc04) This seems not to be related to fontification, but rather to something that c-neutralize-syntax-in-CPP does during C Mode initialization.