From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Default compiler optimization level for building dev sources Date: Fri, 22 Apr 2016 22:18:42 +0200 Message-ID: <87d1phv1lp.fsf@wanadoo.es> References: <87lh45vib7.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1461356364 12099 80.91.229.3 (22 Apr 2016 20:19:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Apr 2016 20:19:24 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 22 22:19:16 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1athXn-0007Gp-9j for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2016 22:19:15 +0200 Original-Received: from localhost ([::1]:39145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1athXm-0003la-Jx for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2016 16:19:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1athXi-0003io-U2 for emacs-devel@gnu.org; Fri, 22 Apr 2016 16:19:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1athXe-0007KC-T5 for emacs-devel@gnu.org; Fri, 22 Apr 2016 16:19:10 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:43520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1athXe-0007K7-M6 for emacs-devel@gnu.org; Fri, 22 Apr 2016 16:19:06 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1athXd-0007BZ-IO for emacs-devel@gnu.org; Fri, 22 Apr 2016 22:19:05 +0200 Original-Received: from 120.red-88-22-75.staticip.rima-tde.net ([88.22.75.120]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Apr 2016 22:19:05 +0200 Original-Received: from ofv by 120.red-88-22-75.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Apr 2016 22:19:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 31 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 120.red-88-22-75.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) Cancel-Lock: sha1:H7MO2esB1j0aOX/f63Qny5gE5sg= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:203191 Archived-At: John Wiegley writes: >>>>>> Óscar Fuentes writes: > >> I'm using Emacs 25.0.92 on Windows and it seems remarkably slower than the >> previous binary. This one was built with a plain config && make while the >> previous one had CFLAGS set to -O3 and other extra optimization flags. > > What flavor of slowness do you experience? Certain operations which used to take a somewhat annoying long time now are almost unbearable. Mostly Magit-related. > One thing I've noticed with 25.0.92 and OS X is that Emacs 25 can be very > "pausy". That is, I'll do something (even just switch buffers), and suddenly > Emacs is locked for about 5-10 seconds, with absolutely no indication before > or after of what is happening. Maybe it's GC? I see something like this on VMs, but for now I tend to attribute the problem to the VM itself, not to Emacs proper. > Especially with ERC, this is quite noticeable because it happens in the middle > of a conversation. In Emacs 24 I never experienced this much stalling (just a > little bit). > > However, this has been impossible to track down thus far; but I wonder if what > you're seeing is at all similar. I don't think so. The problems I observe are more related to a general slow down than to occassional unresponsiveness.