Skip to main content
Emacs

Return to Question

added 54 characters in body
Source Link
VF1
VF1
  • 213
  • 1
  • 6

Opening a small python file, with <10 buffers open, takes a long time. Here's a gist of the profile of trying to open this file (giving up with C-g after 2 minutes).

Deactivating ido-mode tells more or less the same story. See this gist for details.

Messages during the opening of the file:

CPU profiler started
Mark saved where search started [3 times]
Making python-shell-interpreter local to  *Python Internal [792caf12c778150badeeede64c068cee]* while let-bound!
Making python-shell-interpreter-args local to  *Python Internal [792caf12c778150badeeede64c068cee]* while let-bound!
Waiting for process to die...done
Quit

What's amazing is that after I quit the find-file with C-g, and re-open the same file with C-x C-f again, it loads, instantly. If, after this, I try to newly open another small python files, I have the exact same behavior - first time, emacs hangs, second time, emacs opens the file instantaneously.

None of the minor modes that are active seem threatening (I've removed all the cumbersome ones). Here are the minor modes that are activated in python mode (at least as captured when the file successfully opens the second time).

Version

GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2016-04-17 on lgw01-04, modified by Debian

Modes for buffer that's open while opening the file (same as the ones for the file that will be opened, they're allexcept instead of *scratch*'s lisp-mode it'll be python for the *.py):

Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
Blink-Cursor Column-Number Electric-Indent File-Name-Shadow Font-Lock
Global-Font-Lock Line-Number Menu-Bar Mouse-Wheel Shell-Dirtrack
Tool-Bar Tooltip Transient-Mark

(Information about these minor modes follows the major mode info.)

Lisp Interaction mode defined in `lisp-mode.el':

Opening a small python file, with <10 buffers open, takes a long time. Here's a gist of the profile of trying to open this file (giving up with C-g after 2 minutes).

Deactivating ido-mode tells more or less the same story. See this gist for details.

Messages during the opening of the file:

CPU profiler started
Mark saved where search started [3 times]
Making python-shell-interpreter local to  *Python Internal [792caf12c778150badeeede64c068cee]* while let-bound!
Making python-shell-interpreter-args local to  *Python Internal [792caf12c778150badeeede64c068cee]* while let-bound!
Waiting for process to die...done
Quit

What's amazing is that after I quit the find-file with C-g, and re-open the same file with C-x C-f again, it loads, instantly. If, after this, I try to newly open another small python files, I have the exact same behavior - first time, emacs hangs, second time, emacs opens the file instantaneously.

None of the minor modes that are active seem threatening (I've removed all the cumbersome ones). Here are the minor modes that are activated in python mode (at least as captured when the file successfully opens the second time).

Version

GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2016-04-17 on lgw01-04, modified by Debian

Modes for buffer that's open while opening the file (same as the ones for the file that will be opened, they're all *.py):

Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
Blink-Cursor Column-Number Electric-Indent File-Name-Shadow Font-Lock
Global-Font-Lock Line-Number Menu-Bar Mouse-Wheel Shell-Dirtrack
Tool-Bar Tooltip Transient-Mark

(Information about these minor modes follows the major mode info.)

Lisp Interaction mode defined in `lisp-mode.el':

Opening a small python file, with <10 buffers open, takes a long time. Here's a gist of the profile of trying to open this file (giving up with C-g after 2 minutes).

Deactivating ido-mode tells more or less the same story. See this gist for details.

Messages during the opening of the file:

CPU profiler started
Mark saved where search started [3 times]
Making python-shell-interpreter local to  *Python Internal [792caf12c778150badeeede64c068cee]* while let-bound!
Making python-shell-interpreter-args local to  *Python Internal [792caf12c778150badeeede64c068cee]* while let-bound!
Waiting for process to die...done
Quit

What's amazing is that after I quit the find-file with C-g, and re-open the same file with C-x C-f again, it loads, instantly. If, after this, I try to newly open another small python files, I have the exact same behavior - first time, emacs hangs, second time, emacs opens the file instantaneously.

None of the minor modes that are active seem threatening (I've removed all the cumbersome ones). Here are the minor modes that are activated in python mode (at least as captured when the file successfully opens the second time).

Version

GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2016-04-17 on lgw01-04, modified by Debian

Modes for buffer that's open while opening the file (same as the ones for the file that will be opened, except instead of *scratch*'s lisp-mode it'll be python for the *.py):

Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
Blink-Cursor Column-Number Electric-Indent File-Name-Shadow Font-Lock
Global-Font-Lock Line-Number Menu-Bar Mouse-Wheel Shell-Dirtrack
Tool-Bar Tooltip Transient-Mark

(Information about these minor modes follows the major mode info.)

Lisp Interaction mode defined in `lisp-mode.el':
deleted 858 characters in body; edited tags; edited title
Source Link
VF1
VF1
  • 213
  • 1
  • 6

Why does opening a file take so long with code completionin python mode?

Here's the profiler output of me openingOpening a small python file, with <10 buffers open, takes a long time. Here's a gist of the profile of trying to open this file (and givinggiving up with C-g after >10s2 minutes) with just a couple buffers open. The file is

Deactivating ido-mode tells more or less than a few hundred linesthe same story. See this gist for details.

Messages during the opening of the file:

- command-execute                                                 749  97%
 - call-interactively                                             749  97%
  - byte-code                                                     620  80%
   - read-extended-command                                        620  80%
    - completing-read                                             620  80%
     - completing-read-default                                    620  80%
      - read-from-minibuffer                                      575  74%
       - command-execute                                          472CPU profiler 61%started
    - call-interactively                                  Mark saved where search 472started [3 61%times]
    Making python- minibuffershell-complete                                    472 interpreter 61%
local to  *Python Internal [792caf12c778150badeeede64c068cee]* -while completion-inlet-region                                  472  61%bound!
       -Making completionpython-shell-ininterpreter-region                                472  61%
        + #<compiled 0xce0099>                             args local to 472 *Python 61%
Internal [792caf12c778150badeeede64c068cee]* +while ido-findlet-file                                                 101  13%bound!
  + execute-extended-command                                       28Waiting for process 3%
+to die...                                                              17   2%done
  timer-event-handler                                               4   0%Quit

WhatWhat's amazing is going on withthat after I quit the "completion"? This issue came all of suddenfind-file with C-g, I didn't start using a new packageand re-open the same file with C-x C-f again, thoughit loads, instantly. If, after this, I don't frequently code intry to newly open another small python files, and this started happening more and more since I didhave the exact same behavior - first time, emacs hangs, second time, emacs opens the file instantaneously.

What can I do to fix this? None of the minor modes that are active seem threatening (I've removed all the cumbersome ones). Here are the minor modes that are activated in python mode (at least as captured when the file successfully opens the second time).

Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
Blink-Cursor Column-Number Company Electric-Indent File-Name-Shadow
Flycheck Font-Lock Global-Company Global-Flycheck  
Global-Font-Lock
Global-Semantic-Idle-Scheduler Global-Semanticdb Global-Ycmd
Line-Number Menu-Bar Mouse-Wheel Semantic Semantic-Idle-Scheduler
Shell-Dirtrack  
Tool-Bar Tooltip Transient-Mark

(Information Yasabout Yas-Globalthese Ycmd

Pythonminor modemodes definedfollows inthe `pythonmajor mode info.el':)
Major
Lisp modeInteraction formode editingdefined Pythonin files`lisp-mode.el':

I feel like this might just be two redundant autocompletes being on - I have no idea why semantic-mode is on, would that be causing this issue?

Update: I figured out why semantic is on - I turn it on for python-mode only (though I'm struggling to remember why). Either way, even with it on for non-python files; those load quickly. So something about python is causing the issue.

Why does opening a file take so long with code completion?

Here's the profiler output of me opening a file (and giving up after >10s) with just a couple buffers open. The file is less than a few hundred lines.

- command-execute                                                 749  97%
 - call-interactively                                             749  97%
  - byte-code                                                     620  80%
   - read-extended-command                                        620  80%
    - completing-read                                             620  80%
     - completing-read-default                                    620  80%
      - read-from-minibuffer                                      575  74%
       - command-execute                                          472  61%
    - call-interactively                                      472  61%
     - minibuffer-complete                                    472  61%
      - completion-in-region                                  472  61%
       - completion--in-region                                472  61%
        + #<compiled 0xce0099>                                472  61%
  + ido-find-file                                                 101  13%
  + execute-extended-command                                       28   3%
+ ...                                                              17   2%
  timer-event-handler                                               4   0%

What is going on with the "completion"? This issue came all of sudden, I didn't start using a new package, though I don't frequently code in python, and this started happening more and more since I did.

What can I do to fix this?

Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
Blink-Cursor Column-Number Company Electric-Indent File-Name-Shadow
Flycheck Font-Lock Global-Company Global-Flycheck Global-Font-Lock
Global-Semantic-Idle-Scheduler Global-Semanticdb Global-Ycmd
Line-Number Menu-Bar Mouse-Wheel Semantic Semantic-Idle-Scheduler
Shell-Dirtrack Tool-Bar Tooltip Transient-Mark Yas Yas-Global Ycmd

Python mode defined in `python.el':
Major mode for editing Python files.

I feel like this might just be two redundant autocompletes being on - I have no idea why semantic-mode is on, would that be causing this issue?

Update: I figured out why semantic is on - I turn it on for python-mode only (though I'm struggling to remember why). Either way, even with it on for non-python files; those load quickly. So something about python is causing the issue.

Why does opening a file take so long in python mode?

Opening a small python file, with <10 buffers open, takes a long time. Here's a gist of the profile of trying to open this file (giving up with C-g after 2 minutes).

Deactivating ido-mode tells more or less the same story. See this gist for details.

Messages during the opening of the file:

CPU profiler started
Mark saved where search started [3 times]
Making python-shell-interpreter local to  *Python Internal [792caf12c778150badeeede64c068cee]* while let-bound!
Making python-shell-interpreter-args local to  *Python Internal [792caf12c778150badeeede64c068cee]* while let-bound!
Waiting for process to die...done
Quit

What's amazing is that after I quit the find-file with C-g, and re-open the same file with C-x C-f again, it loads, instantly. If, after this, I try to newly open another small python files, I have the exact same behavior - first time, emacs hangs, second time, emacs opens the file instantaneously.

None of the minor modes that are active seem threatening (I've removed all the cumbersome ones). Here are the minor modes that are activated in python mode (at least as captured when the file successfully opens the second time).

Enabled minor modes: Auto-Composition Auto-Compression Auto-Encryption
Blink-Cursor Column-Number Electric-Indent File-Name-Shadow Font-Lock 
Global-Font-Lock Line-Number Menu-Bar Mouse-Wheel Shell-Dirtrack 
Tool-Bar Tooltip Transient-Mark

(Information about these minor modes follows the major mode info.)

Lisp Interaction mode defined in `lisp-mode.el':
[Edit removed during grace period]
Source Link
VF1
VF1
  • 213
  • 1
  • 6
added 247 characters in body
Source Link
VF1
VF1
  • 213
  • 1
  • 6
Source Link
VF1
VF1
  • 213
  • 1
  • 6