From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.help Subject: Re: 100% CPU usage on emacs startup Date: Sat, 02 Feb 2019 08:38:46 +0100 Message-ID: <86y36yod15.fsf@dod.no> References: <86fttbpd7q.fsf@dod.no> <867eekpucc.fsf@dod.no> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="159889"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (windows-nt) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Feb 02 08:43:28 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gppxY-000fVy-2J for geh-help-gnu-emacs@m.gmane.org; Sat, 02 Feb 2019 08:43:28 +0100 Original-Received: from localhost ([127.0.0.1]:38791 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gppxW-0006gk-VL for geh-help-gnu-emacs@m.gmane.org; Sat, 02 Feb 2019 02:43:27 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gpptL-0003nQ-S8 for help-gnu-emacs@gnu.org; Sat, 02 Feb 2019 02:39:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gpptK-0002S1-Kh for help-gnu-emacs@gnu.org; Sat, 02 Feb 2019 02:39:07 -0500 Original-Received: from cadalora.default.sbang.uk0.bigv.io ([46.43.15.90]:36134 helo=cadalora.bang.priv.no) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gpptK-0002KV-DR for help-gnu-emacs@gnu.org; Sat, 02 Feb 2019 02:39:06 -0500 Original-Received: from mccoy (cm-84.212.50.160.getinternet.no [84.212.50.160]) by cadalora.bang.priv.no (Postfix) with ESMTPSA id 6E807CD344 for ; Sat, 2 Feb 2019 07:38:47 +0000 (GMT) In-Reply-To: <867eekpucc.fsf@dod.no> (Steinar Bang's message of "Thu, 31 Jan 2019 19:14:59 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 46.43.15.90 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:119196 Archived-At: >>>>> Steinar Bang : >>>>> Steinar Bang : >> Platform: debian 9.7 "stretch", amd64, emacs 25.1+1-4+deb9u1, >> jdee 20180831.1500 (from melpa) >> I'm getting a lot of messages like this, when exiting emacs, and when >> running M-x compile : >> Save file /tmp/JDEE_flycheck_16412_kQ/Role.java? (y, n, !, ., q, C-r or C-h) > This problem seems to have gone away, however... I think the reason the temp file went away was that I defined the jdee-server-dir to point to a directory containing the jar file of the jdee server https://github.com/jdee-emacs/jdee-server >> An extra datapoint: I'm using emacs-desktop to restore the desktop where >> this occurs. I don't know if that's significant or not? > When starting up and restoring the desktop emacs uses 100% of one of the > cores, and after 1h of starup still hasn't completed (and this is a > pretty fast machine). > Does anyone know what causes this? Is emacs-desktop restore and JDEE > just a bad mix? I think this is the case. In one case emacs eventually came up restored after 1h 15 minutes of 100% CPU usage on one of the cores of a 3.5GHz Intel i5-6600 "Skylake" CPU. However, I removed JDEE, and tried a restore, and emacs desktop restore was taking too long to restore to be useful (I didn't let it run its course so I don't know exactly too long). So I reinstalled JDEE (which does Java formatting a lot better than the plain old java-mode) and removed the .emacs.desktop and started fresh and now it works good enough again. So I guess the simplest solution is to simply delete the .emacs.desktop once emacs startup becomes too slow to be useful. It's good enough for my use case, which is basically to continue where I was yesterday, and if I have to restart from time to time it's no worse than when I have to restore my desktop because and OS update causes a system restart.