[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs/prelude: lag in opening big files
From: |
Eli Zaretskii |
Subject: |
Re: Emacs/prelude: lag in opening big files |
Date: |
Fri, 21 Jul 2017 16:43:50 +0300 |
> From: Vikas Rawal <vikaslists@agrarianresearch.org>
> Date: Fri, 21 Jul 2017 07:37:55 +0530
>
> I am having a strange problem that I have never faced before. When I open
> (C-f) a large file, it gets stuck for a long time. I have to wait for
> eternity before the file would open. But if I C-g and cancel the process, and
> do it again, the second time, it opens in a snap.
> I have tried it with many files, and it happens each time. If a file is
> opened and closed, and I want to open it again, emacs does the same thing all
> over again. That is, slow to open first time, but opens in a snap if I C-g
> and start again.
>
> How do I debug this? I tried to use profiler to figure out where was emacs
> stuck. Below is the main part of the report on cpu usage when I tried to open
> a large org mode file. Looks like helm is one of the culprits. Is this usual?
> Is there a way to deal with this?
>
> Vikas
>
>
>
>
> - command-execute 6903 57%
> - call-interactively 6903 57%
> - funcall-interactively 6575 54%
> - helm-find-files 6575 54%
> - helm-find-files-1 6575 54%
> - helm 6575 54%
> - apply 6575 54%
> - helm 6575 54%
> - apply 6575 54%
> - helm-internal 6575 54%
> - helm-execute-selection-action 6103 50%
> - helm-execute-selection-action-1 6103 50%
> - helm-find-file-or-marked 6102 50%
> - apply 6102 50%
> + #<compiled 0x40bf3dad> 6102 50%
> + helm-get-actions-from-current-source 1 0%
You stopped expanding the profile too early: you should continue
expanding "#<compiled 0x40bf3dad>" and the levels below it, until you
find a significant change in the percentage -- that is where most of
the CPU processing is spent. (My guess would be it's
org-indent-add-properties, but that's just a guess.) For more
accurate profile, load all the libraries involved in this as *.el
files, not as *.elc.
(This should probably be a bug report.)