On 2016-06-24 09:56, Eli Zaretskii wrote:
> Looks like redisplay is indeed an important factor here.
> 
> In addition, it looks like you have some subprocess from which you
> read input?  What's the part of profile below about?
> 
>   - scomint-output-filter                                           173  26%
>    - run-hook-with-args                                             173  26%
>     - proof-shell-filter-wrapper                                    169  26%
>      - byte-code                                                    169  26%
>       - proof-shell-filter                                          160  24%
>        - proof-shell-filter-manage-output                           137  21%
> 	- proof-shell-exec-loop                                     123  19%
> 	 - mapc                                                      95  14%
> 	  - proof-shell-invoke-callback                              93  14%
> 	   - byte-code                                               93  14%
> 	    - proof-done-advancing                                   93  14%
> 
> Can you write some high-level overview of what the inner loop of your
> code does, including what is being redisplayed, and how input from
> subprocesses enters the picture?

This is in the context of a package called proof general. It's an interface for proof assistants. Essentially you write a sequence of commands, and ask the proof assistant to process them one by one.

The proof-shell functions do this: they handle communication with the subprocess. The main loop looks like this:

* Fetch one command from the buffer
* Send it to the subprocess
* When a response arrives, call a hook
* Send the next command

My code adds a functioon into that hook that calls set-window-buffer; when I remove that call, everything is snappy. When I add it back in, everything gets much slower (at least that's what I understand; this isn't happening on my machine).

> In addition, I suggest to run your benchmark several times, so as to
> eliminate the significant portion of time execute-extended-command and
> its subroutines, and the profiler itself, show in the profile?  Also,
> load all the Lisp libraries as *.el files, so that the profile is more
> detailed.

OK, I'll ask the person who's seeing that bug to generate this report.

Thanks for your help!
Clément.