How to profile restoring from .emacs.desktop

How to profile restoring from .emacs.desktop

[Steinar Bang]

Platform: emacs 26.1 on debian 10.7 "buster", amd64

Using emacs.desktop on my development area works fine at first, but
startup fairly quickly becomes so slow that the only possibility is to
delete the .emacs.desktop and start fresh.

It would be interesting to find out where emacs spends its time when
restoring from an .emacs.desktop file.

Is it possible to profile the restore from .emacs.desktop in some way?

Thanks!


- Steinar

Re: How to profile restoring from .emacs.desktop

[Stefan Monnier]

Hi Steinar,

> Is it possible to profile the restore from .emacs.desktop in some way?

You can add

    (profiler-start 'cpu)

in your init file somewhere before loading the `.emacs.desktop` and then
call `M-x profiler-report` when the startup is done (or call
`(profiler-report)` at the end of your init file, tho I've never tried
that and there's a chance/risk that the desktop loading actually
continues long after the end of init file so it may capture too short
a profile).


        Stefan

Re: How to profile restoring from .emacs.desktop

[Steinar Bang]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca>:

> Hi Steinar,
>> Is it possible to profile the restore from .emacs.desktop in some way?

> You can add

>     (profiler-start 'cpu)

> in your init file somewhere before loading the `.emacs.desktop` and then
> call `M-x profiler-report` when the startup is done

Thanks, Stefan!

I did exactly that:
 1. Put (profiler-start 'cpu) at the end of ~/.emacs
 2. Did `M-x profiler-report` after the startup has completed

And it worked perfectly!

I succeeded in saving the profile to a file.  I have no idea how/if it
can be loaded from that file, but the saved profile is here:
 https://gist.github.com/steinarb/fbb854a40f058cf561cbc333f64bc967

But a deep analysis probably isn't necessary, opening the biggest nodes
in the profile, it's pretty obvious that the biggest culprit is
projectile-discover-projects-in-directory the function it calls, with
the biggest chunks, before it all breaks down into many small things,
are projectile-serialize and projectile-difference.

So it's projectile project discovery that spends most of the time.
I wonder if that information can be cached...?

Here's the profiler tree with the most interesting (to me) nodes opened:

- normal-top-level                                             116518  92%
 - command-line                                                116518  92%
  - command-line-1                                             116510  92%
   - eval                                                      116506  92%
    - progn                                                    116506  92%
     - desktop-read                                            116506  92%
      - load                                                   116355  92%
       - load-with-code-conversion                             116355  92%
        - eval-buffer                                          116346  92%
         - desktop-create-buffer                               116281  92%
          - projectile-mode                                    102201  81%
           - projectile-discover-projects-in-search-path              96086  76%
            - mapcar                                            96086  76%
             - projectile-discover-projects-in-directory              96086  76%
              - mapcar                                          95579  75%
               - #<compiled 0x10bffb5>                          95540  75%
                - projectile-add-known-project                  90190  71%
                 - projectile-merge-known-projects              85962  68%
                  - projectile-save-known-projects              45969  36%
                   - projectile-serialize                       43930  34%
                    + write-region                              11854   9%
                    + #<compiled 0x134d99d>                      1988   1%
                    + get-buffer-create                           106   0%
                  - projectile-difference                       18874  14%
                   - cl-remove-if                               18650  14%
                    - apply                                     18631  14%
                       cl-remove                                12671  10%
                  + projectile-unserialize                      15287  12%
                    delete-dups                                  3281   2%
                 + abbreviate-file-name                          1425   1%
                   delete-dups                                   1081   0%
                 + projectile-ignored-project-p                    37   0%
                + projectile-project-p                           4587   3%
                directory-files                                    13   0%
           + projectile--cleanup-known-projects                  5784   4%
           + projectile-load-known-projects                       210   0%
           + projectile-commander-bindings                         53   0%
           + advice-add                                            36   0%
           + called-interactively-p                                 3   0%
             add-hook                                               2   0%
          + desktop-restore-file-buffer                          7532   5%
          + dired-restore-desktop-buffer                         3346   2%
          + desktop-load-file                                    1498   1%
          + bury-buffer                                          1081   0%
          + rename-buffer                                         476   0%
          + auto-revert-mode                                       71   0%
          + flycheck-mode                                          12   0%
          + editorconfig-mode                                       9   0%
          + nxml-psgml-compatibility-mode                           4   0%
            buffer-list                                             4   0%
          + auto-fill-mode                                          4   0%
         + internal-macroexpand-for-load                           11   0%
        + do-after-load-evaluation                                  9   0%
      + desktop-restore-frameset                                  147   0%
      + byte-code                                                   4   0%
  + lisp-interaction-mode                                           4   0%
- ...                                                            8332   6%
   Automatic GC                                                  8299   6%
 + minibuffer-complete                                             25   0%
 + cl--generic-get-dispatcher                                       4   0%
 + rng-compute-start-tag-close-deriv                                4   0%
+ timer-event-handler                                            1021   0%
+ command-execute                                                 108   0%
+ redisplay_internal (C function)                                  67   0%
+ flycheck-handle-signal                                           12   0%
+ flycheck-hide-error-buffer                                        3   0%

Re: How to profile restoring from .emacs.desktop

[Stefan Monnier]

> But a deep analysis probably isn't necessary, opening the biggest nodes
> in the profile, it's pretty obvious that the biggest culprit is
> projectile-discover-projects-in-directory the function it calls, with
> the biggest chunks, before it all breaks down into many small things,
> are projectile-serialize and projectile-difference.
>
> So it's projectile project discovery that spends most of the time.
> I wonder if that information can be cached...?

I don't use Projectile and never looked at its code, so I can't
answer that.  I don't know either how Projectile compares to Emacs's
builtin support for projects (tho I expect it's significantly more
featureful), but you may want to try that builtin support instead of
Projectile to see if it suffers from a similar problem, and/or if it
provides the subset of features you happen to use.


        Stefan

Re: How to profile restoring from .emacs.desktop

[Steinar Bang]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca>:

>> So it's projectile project discovery that spends most of the time.
>> I wonder if that information can be cached...?

> I don't use Projectile and never looked at its code, so I can't answer
> that.

I googled and found this: https://stackoverflow.com/a/50997907

I changed the script I use to restore an emacs tunnelled over an SSH X
forwarding from:
 #!/bin/sh
 #
 # Brukes til å sparke igang eclipse og emacs når jeg tar en ssh til lorenzo
 #
 export REPOUSER=maven
 cd ~/workspaces
 emacs --eval "(progn (desktop-read)(desktop-save-mode 1))" >/dev/null 2>&1 &
to
 #!/bin/sh
 #
 # Brukes til å sparke igang eclipse og emacs når jeg tar en ssh til lorenzo
 #
 export REPOUSER=maven
 cd ~/workspaces
 emacs --eval "(progn (setq projectile-enable-caching 't)(desktop-read)(desktop-save-mode 1))" >/dev/null 2>&1 &

I then started emacs once and stopped it, and started emacs again with
profiling on.

The caching didn't seem to have much effect.  See the opened profiling
below.

C-h v projectile-enable-caching says:
 projectile-enable-caching is a variable defined in ‘projectile.el’.
 Its value is t
 Original value was nil

(ie. the variable was successfully set)

> I don't know either how Projectile compares to Emacs's builtin support
> for projects (tho I expect it's significantly more featureful), but
> you may want to try that builtin support instead of Projectile to see
> if it suffers from a similar problem, and/or if it provides the subset
> of features you happen to use.

Sounds interesting.

I've googled this as well and the one hit I found was emacs 28:
 https://www.gnu.org/software/emacs/manual/html_node/emacs/Projects.html

Is this emacs 28 only?

(I'm still on emacs 26 and 27)

Here's the profile from starting up with a projectile cache in place:
- normal-top-level                                             116753  92%
 - command-line                                                116753  92%
  - command-line-1                                             116749  92%
   - eval                                                      116749  92%
    - progn                                                    116749  92%
     - desktop-read                                            116745  92%
      - load                                                   116609  92%
       - load-with-code-conversion                             116609  92%
        - eval-buffer                                          116602  92%
         - desktop-create-buffer                               116501  92%
          - projectile-mode                                    102763  81%
           - projectile-discover-projects-in-search-path              96535  76%
            - mapcar                                            96535  76%
             - projectile-discover-projects-in-directory              96535  76%
              - mapcar                                          96039  76%
               - #<compiled 0xf66071>                           96009  76%
                - projectile-add-known-project                  90801  72%
                 - projectile-merge-known-projects              86378  68%
                  - projectile-save-known-projects              46828  37%
                   - projectile-serialize                       44868  35%
                    - write-region                              12417   9%
                     - select-safe-coding-system                11873   9%
                      - find-auto-coding                         9805   7%
                         auto-coding-alist-lookup                3012   2%
                         sgml-html-meta-auto-coding-function               1011   0%
                         auto-coding-regexp-alist-lookup                540   0%
                         sgml-xml-auto-coding-function                392   0%
                      + mapcar                                     58   0%
                        find-coding-systems-region                 43   0%
                        coding-system-get                          26   0%
                        coding-system-type                         22   0%
                    + #<compiled 0x124135d>                      2120   1%
                    + get-buffer-create                            68   0%
                  - projectile-difference                       17815  14%
                   - cl-remove-if                               17598  14%
                    - apply                                     17580  13%
                       cl-remove                                11888   9%
                  - projectile-unserialize                      15191  12%
                   + insert-file-contents                        5195   4%
                   + #<compiled 0x119c0b9>                       3287   2%
                   + generate-new-buffer                          838   0%
                    delete-dups                                  3816   3%
                 + abbreviate-file-name                          1526   1%
                   delete-dups                                   1263   1%
                 + projectile-ignored-project-p                    20   0%
                + projectile-project-p                           4475   3%
                directory-files                                    11   0%
           + projectile--cleanup-known-projects                  5847   4%
           + projectile-load-known-projects                       236   0%
           + projectile-commander-bindings                         64   0%
           + advice-add                                            56   0%
             called-interactively-p                                 1   0%
          + desktop-restore-file-buffer                          7767   6%
          + dired-restore-desktop-buffer                         3833   3%
          + bury-buffer                                          1074   0%
          + rename-buffer                                         529   0%
          + desktop-load-file                                     338   0%
          + auto-revert-mode                                       52   0%
          + flycheck-mode                                          33   0%
            editorconfig-mode                                       8   0%
            buffer-list                                             4   0%
          + nxml-psgml-compatibility-mode                           3   0%
          + smerge-mode                                             3   0%
         + internal-macroexpand-for-load                           23   0%
        + do-after-load-evaluation                                  7   0%
      + desktop-restore-frameset                                  136   0%
    #<compiled 0x1dda91>                                            4   0%
+ ...                                                            8194   6%
+ timer-event-handler                                             563   0%
+ command-execute                                                  99   0%
+ redisplay_internal (C function)                                  34   0%
+ flycheck-handle-signal                                            8   0%

Re: How to profile restoring from .emacs.desktop

[Stefan Monnier]

> The caching didn't seem to have much effect.  See the opened profiling
> below.
>
> C-h v projectile-enable-caching says:
>  projectile-enable-caching is a variable defined in ‘projectile.el’.
>  Its value is t
>  Original value was nil
>
> (ie. the variable was successfully set)

You might want to file a bug report with the maintainer of Projectile, then.
Clearly, your profile indicates that it's doing "too much work".

>> I don't know either how Projectile compares to Emacs's builtin support
>> for projects (tho I expect it's significantly more featureful), but
>> you may want to try that builtin support instead of Projectile to see
>> if it suffers from a similar problem, and/or if it provides the subset
>> of features you happen to use.
>
> Sounds interesting.
>
> I've googled this as well and the one hit I found was emacs 28:
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Projects.html
>
> Is this emacs 28 only?

It was introduced in Emacs-25, with extremely limited functionality.
Its functionality has grown a bit since, but it's still very minimal.
It's more thought as something on top of which other tools (like xref)
can provide features.

> (I'm still on emacs 26 and 27)

I think there was nothing new for it in Emacs-26, but Emacs-27 did spice
it up a bit (check the NEWS file for more info).


        Stefan

Re: How to profile restoring from .emacs.desktop

[Dmitry Gutov]

On 29.01.2021 00:58, Stefan Monnier wrote:
> It was introduced in Emacs-25, with extremely limited functionality.
> Its functionality has grown a bit since, but it's still very minimal.
> It's more thought as something on top of which other tools (like xref)
> can provide features.
> 
>> (I'm still on emacs 26 and 27)
> I think there was nothing new for it in Emacs-26, but Emacs-27 did spice
> it up a bit (check the NEWS file for more info).

And it's grown again a bit in Emacs 28, with a global keymap and a set 
of project-scoped commands in it, among other things.

Most importantly, you can install the latest version of project.el 
inside Emacs 26 or 27 from GNU ELPA.

project-mode vs projectile (Was: How to profile restoring from .emacs.desktop)

[Steinar Bang]

>>>>> Dmitry Gutov <dgutov@yandex.ru>:

> On 29.01.2021 00:58, Stefan Monnier wrote:
(on project-mode)

>> It was introduced in Emacs-25, with extremely limited functionality.
>> Its functionality has grown a bit since, but it's still very minimal.
>> It's more thought as something on top of which other tools (like xref)
>> can provide features.
>> 
>>> (I'm still on emacs 26 and 27)
>> I think there was nothing new for it in Emacs-26, but Emacs-27 did spice
>> it up a bit (check the NEWS file for more info).

> And it's grown again a bit in Emacs 28, with a global keymap and a set
> of project-scoped commands in it, among other things.

> Most importantly, you can install the latest version of project.el
> inside Emacs 26 or 27 from GNU ELPA.

Maybe it is time for me to try project-mode out again, then?

Is there an overview on what kind of commands are available in the emacs
28 project-mode?

By this time I have about 6 months of actively using projectile (once I
got the startup issues cleared away and using the cache instead), and
I've quite grown to like it.

I have replaced navigating with switch-to-buffer with the
projectile-find-file file command, and switch between projects with
projectile-switch-open-project command and find a directory with the
projectile-find-dir command (the find file and find dir commands stay
within a project).

So that has mostly replaced my need for .emacs.desktop.
(The only reason I'm still using .emacs.desktop, is to restore the open
windows.  Is it possible to have .emacs.desktop restore windows but not
files?)

Other useful commands:
 - projectile-grep which rgreps inside a project useful
 - projectile-compile-project (very useful for maven projects, where the
   mvn command must be run at the top directory of the project far from
   the file being edited)
 - projectile-find-tag (very useful, once I was able to make CTAGS
   recognize ES6 javascript)

What I'm missing are commands that do the same thing as the project
level commands for project modules, in particular for maven multi-module
projects.

The most important command to get a module command for is the compile
command (because building a single module takes a lot less time than
building the entire reactor build), but module specific search and
navigate commands would also be useful.

Does project-mode have a concept of modules? (the maven concept of
modules is what's in my mind)

Thanks!


- Steinar

Re: project-mode vs projectile (Was: How to profile restoring from .emacs.desktop)

[Dmitry Gutov]

Hi!

Sorry for the late reply.

On 19.06.2021 12:02, Steinar Bang wrote:

>> And it's grown again a bit in Emacs 28, with a global keymap and a set
>> of project-scoped commands in it, among other things.
> 
>> Most importantly, you can install the latest version of project.el
>> inside Emacs 26 or 27 from GNU ELPA.
> 
> Maybe it is time for me to try project-mode out again, then?

First of all, it's not a mode. A recent enough version of project.el 
just installs a global keymap and lets you use its bindings.

One advantage is it doesn't run any code (e.g. root-finding code) until 
you actually use one of the related commands.

> Is there an overview on what kind of commands are available in the emacs
> 28 project-mode?

'C-x p C-h' should give you a reasonably complete list.

> By this time I have about 6 months of actively using projectile (once I
> got the startup issues cleared away and using the cache instead), and
> I've quite grown to like it.

I've used it for years, it's a handy package. project.el started out as 
a kind of backdoor to be able to use projectile indirectly in core Emacs 
commands. That still hasn't panned out exactly, but I'm hopeful on that 
front too.

> I have replaced navigating with switch-to-buffer with the
> projectile-find-file file command, and switch between projects with
> projectile-switch-open-project command and find a directory with the
> projectile-find-dir command (the find file and find dir commands stay
> within a project).

There is still no 'project-find-dir' command, but we should add one. 
There is a related bug report somewhere in debbugs.

> Other useful commands:
>   - projectile-grep which rgreps inside a project useful
>   - projectile-compile-project (very useful for maven projects, where the
>     mvn command must be run at the top directory of the project far from
>     the file being edited)
>   - projectile-find-tag (very useful, once I was able to make CTAGS
>     recognize ES6 javascript)

There are counterparts to the first two, but what does the last one do? 
It's it basically the same as xref-find-definitions?

> What I'm missing are commands that do the same thing as the project
> level commands for project modules, in particular for maven multi-module
> projects.
> 
> The most important command to get a module command for is the compile
> command (because building a single module takes a lot less time than
> building the entire reactor build), but module specific search and
> navigate commands would also be useful.
> 
> Does project-mode have a concept of modules? (the maven concept of
> modules is what's in my mind)

No concept of modules as such (though there is a defcustom to decide 
whether to treat "git submodules" as separate projects, but those are 
different kind of modules).

If you want some dedicated support, we'll need to clarify the 
requirements. For instance, would you be happy if mvn modules were 
treated as separate projects? I think that leaves only the "module 
compile command", and that seems somewhat maven-specific. You could 
create a new command which would look up what kind of project the 
current file is in, and invoke some corresponding action.

Or if you want project-compile to provide different behaviors, what 
would it do? Perhaps you'd want to customize compilation-read-command 
instead?

Re: project-mode vs projectile

[Steinar Bang]

>>>>> Dmitry Gutov <dgutov@yandex.ru>:

> First of all, it's not a mode. A recent enough version of project.el
> just installs a global keymap and lets you use its bindings.

Hm... ok. I've seen some bindings mentioned in a google hit, but when I
tried using them on emacs 27 (I don't have a reference to the google hit
handy).

Is this for emacsen newer than 27.1?

> One advantage is it doesn't run any code (e.g. root-finding code)
> until you actually use one of the related commands.

An advantage in performance?

I don't know what projectile does here, but I suspect that, with the
correct configuration (which is *not*, as I found, "scan everything on
startup"...), projectile doesn't do much either, until the commands are
used.

>> Is there an overview on what kind of commands are available in the emacs
>> 28 project-mode?

> 'C-x p C-h' should give you a reasonably complete list.

I get "C-x p is undefined" on emacs 27.1, so I guess I need something
newer than that?

> I've used it for years, it's a handy package. project.el started out
> as a kind of backdoor to be able to use projectile indirectly in core
> Emacs commands. That still hasn't panned out exactly, but I'm hopeful
> on that front too.

Hm... are you saying project.el and projectile are releated somehow?

Up until reading the above I had been thinking they were two
implementations of similar functionality, with project.el being the
native emacs version?

[snip!]
>> projectile-find-dir command (the find file and find dir commands stay
>> within a project).

> There is still no 'project-find-dir' command, but we should add
> one. There is a related bug report somewhere in debbugs.

>> Other useful commands:
>> - projectile-grep which rgreps inside a project useful
>> - projectile-compile-project (very useful for maven projects, where the
>> mvn command must be run at the top directory of the project far from
>> the file being edited)
>> - projectile-find-tag (very useful, once I was able to make CTAGS
>> recognize ES6 javascript)

> There are counterparts to the first two, but what does the last one
> do? It's it basically the same as xref-find-definitions?

I've never used xref-find-definitions, but from the description it looks
to be the same.

[snip1]
>> Does project-mode have a concept of modules? (the maven concept of
>> modules is what's in my mind)

> No concept of modules as such

Ok.

> (though there is a defcustom to decide whether to treat "git
> submodules" as separate projects, but those are different kind of
> modules).

Yes.  Maven modules have the same form as the entire maven project they
are part of.  And they can be run separately by cd'ing into the module
diretory and running the mvn build command (if their dependencies are
fulfilled). 

> If you want some dedicated support, we'll need to clarify the
> requirements. For instance, would you be happy if mvn modules were
> treated as separate projects?

Ideally I would like the project level commands to remain as they are.

But I would like to have a similar set of commands that operate on the
specified module only (search, replace, build, at least).

And maybe a simple way to navigate to a specified module.

> I think that leaves only the "module compile command", and that seems
> somewhat maven-specific. You could create a new command which would
> look up what kind of project the current file is in, and invoke some
> corresponding action.

What I currently do, is have a text file in each project, not commited
to git, and containing canned commands for building each project.

And then I just go to that file, copy them, and then feed them to "M-x
compile" to build a specific project.

But this is cumbersome, and error prone (I have may times built the
wrong module and not understood why my changes weren't showing up) and
cd followed by a command, doesn't work on windows emacs.

Here's an example of such a text file:
 cd ~/workspaces/sampleapp/sampleapp.web.frontend/; mvn -B install -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true
 cd ~/workspaces/sampleapp/sampleapp.db.liquibase.test/; mvn -B install -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true
 cd ~/workspaces/sampleapp/sampleapp.backend/; mvn -B install -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true
 cd ~/workspaces/sampleapp/sampleapp.web.api/; mvn -B install -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true

> Or if you want project-compile to provide different behaviors, what
> would it do? Perhaps you'd want to customize compilation-read-command
> instead?

No, I think what I would like to see, is a concept of "current-module"
(e.g. based on the currently visisted file or directory) and then a
module-compile command

Thanks for responding! :-)


- Steinar

Re: project-mode vs projectile

[Nikolay Kudryavtsev]

project.el currently supports only two backends, one is VC which is not 
very useful if you want any compilation functionality, but the other one 
is EDE, which supports subprojects and having multiple targets per 
project. So in theory you'd need to replace your text files with make 
files and it would work.

Re: project-mode vs projectile

[Dmitry Gutov]

On 05.09.2021 14:35, Steinar Bang wrote:
>>>>>> Dmitry Gutov <dgutov@yandex.ru>:
> 
>> First of all, it's not a mode. A recent enough version of project.el
>> just installs a global keymap and lets you use its bindings.
> 
> Hm... ok. I've seen some bindings mentioned in a google hit, but when I
> tried using them on emacs 27 (I don't have a reference to the google hit
> handy).
> 
> Is this for emacsen newer than 27.1?

Like I said, it's grown a little in Emacs 28. You can install that 
version from GNU ELPA in Emacs 27 as well.

>> One advantage is it doesn't run any code (e.g. root-finding code)
>> until you actually use one of the related commands.
> 
> An advantage in performance?
> 
> I don't know what projectile does here, but I suspect that, with the
> correct configuration (which is *not*, as I found, "scan everything on
> startup"...), projectile doesn't do much either, until the commands are
> used.

It doesn't do "much", but it does stuff, for example,

   (add-hook 'find-file-hook 'projectile-find-file-hook-function)

which isn't too bad by itself but contributes to the "death by a 1000 
cuts" in configurations where many packages are installed. Or when you 
just need to visit many files quickly.

>> I've used it for years, it's a handy package. project.el started out
>> as a kind of backdoor to be able to use projectile indirectly in core
>> Emacs commands. That still hasn't panned out exactly, but I'm hopeful
>> on that front too.
> 
> Hm... are you saying project.el and projectile are releated somehow?

They will be more "related" when Bozhidar gets around to merging the 
"bridging" code which allows Projectile to act as a project.el backend.

Any year now.

>> If you want some dedicated support, we'll need to clarify the
>> requirements. For instance, would you be happy if mvn modules were
>> treated as separate projects?
> 
> Ideally I would like the project level commands to remain as they are.
> 
> But I would like to have a similar set of commands that operate on the
> specified module only (search, replace, build, at least).
> 
> And maybe a simple way to navigate to a specified module.

All right, thanks.

I've outlined my brief thoughts on the subject of module-specific 
functionality in the second part of the email here: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#146

>> I think that leaves only the "module compile command", and that seems
>> somewhat maven-specific. You could create a new command which would
>> look up what kind of project the current file is in, and invoke some
>> corresponding action.
> 
> What I currently do, is have a text file in each project, not commited
> to git, and containing canned commands for building each project.
> 
> And then I just go to that file, copy them, and then feed them to "M-x
> compile" to build a specific project.
> 
> But this is cumbersome, and error prone (I have may times built the
> wrong module and not understood why my changes weren't showing up) and
> cd followed by a command, doesn't work on windows emacs.
> 
> Here's an example of such a text file:
>   cd ~/workspaces/sampleapp/sampleapp.web.frontend/; mvn -B install -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true
>   cd ~/workspaces/sampleapp/sampleapp.db.liquibase.test/; mvn -B install -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true
>   cd ~/workspaces/sampleapp/sampleapp.backend/; mvn -B install -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true
>   cd ~/workspaces/sampleapp/sampleapp.web.api/; mvn -B install -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true

Sounds like it can be automated, with or without project.el integration. 
Though perhaps you'd have to transition to a more structured file format 
like yml/json/lisp. Which might be more of a pain to write.

Cheers,
Dmitry.

Re: How to profile restoring from .emacs.desktop

[Steinar Bang]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca>:

> You might want to file a bug report with the maintainer of Projectile, then.
> Clearly, your profile indicates that it's doing "too much work".

Turns out this was a user error.

I had this setting in ~/.emacs:
 (setq projectile-project-search-path '("~/workspaces/" "~/git/"))

This causes projectile to scan all of the subdirectories of those
directories for project on startup.

And there are a *lot* of project directories to scan under those!

When I removed this setting (defaults to nil), desktop restored in a
much shorter time.

Here's the results of profiler-report from desktop restore, opened on
the interesting nodes: 

- normal-top-level                                              20214  91%
 - command-line                                                 20214  91%
  - command-line-1                                              20206  91%
   - eval                                                       20206  91%
    - progn                                                     20206  91%
     - desktop-read                                             20206  91%
      - load                                                    20040  90%
       - load-with-code-conversion                              20040  90%
        - eval-buffer                                           20026  90%
         - desktop-create-buffer                                19978  90%
          - desktop-restore-file-buffer                          8029  36%
           - find-file-noselect                                  7865  35%
            - find-file-noselect-1                               4813  21%
             - after-find-file                                   4621  20%
              + run-hooks                                        2564  11%
              + normal-mode                                      2020   9%
              + auto-save-mode                                     20   0%
             + file-truename                                      134   0%
             + insert-file-contents                                17   0%
               abbreviate-file-name                                 4   0%
            + create-file-buffer                                  433   1%
            + find-buffer-visiting                                292   1%
            + file-truename                                       210   0%
              abbreviate-file-name                                 42   0%
           + switch-to-buffer                                     147   0%
          + projectile-mode                                      5696  25%
          + dired-restore-desktop-buffer                         3839  17%
          + bury-buffer                                          1411   6%
          + rename-buffer                                         466   2%
          + desktop-load-file                                     359   1%
          + auto-revert-mode                                       62   0%
          + flycheck-mode                                          12   0%
            visual-line-mode                                        6   0%
            editorconfig-mode                                       5   0%
            buffer-list                                             2   0%
         + internal-macroexpand-for-load                           12   0%
        + do-after-load-evaluation                                 12   0%
      + desktop-restore-frameset                                  162   0%
      + byte-code                                                   4   0%
  + lisp-interaction-mode                                           4   0%
+ ...                                                            1360   6%
+ timer-event-handler                                             486   2%
+ command-execute                                                  98   0%
+ redisplay_internal (C function)                                  34   0%
+ flycheck-handle-signal                                            4   0%