Subject: bug#29846: closed (Re: bug#29846: scroll and fontify takes longer time for file in slow network)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 28 Dec 2017 19:04:02 +0000

Your bug report

#29846: scroll and fontify takes longer time for file in slow network

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
29846: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29846
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#29846: scroll and fontify takes longer time for file in slow network
From: Stefan Monnier <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked]
Date: Thu, 28 Dec 2017 14:03:47 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

>> I believe this bug was introduced by yours truly
>> in commit 6bc76cee212aab0a2c02f8c28213fc842cc7880f:
[...]
>> And I think the patch below hence belongs in emacs-26.  Any objection?
> LGTM, please push to emacs-26.

Installed,

        Stefan

Subject: scroll and fontify takes longer time for file in slow network
From: Shuguang Sun <[email-masked]>
To: [email-masked]
Date: Mon, 25 Dec 2017 14:03:43 +0800
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

Windows 7, GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) of 2017-12-09.

Issue:
I have remote dirver (//server/path) mapped to my windows system (samba?).
The network is slow, and it takes some time to open the file. However,
after I have the file opened and scroll down, it takes a long time to
scroll to the next screen. It gets worse if the jit-lock-debug-mode is on.
After that if I try to scroll back to those has been fontified, it get
fluent as expected.

If I open the same file in a local driver (speed is higher than the network
definitely), the scroll is very fluent.

If I open a txt file (fundmental-mode, not fontification) in the same
remote directory, the scroll actions are fluent as well.

Per my understanding, all actions should be done in memory when a file has
been read into buffer, except backup, autosave, etc. The response should
not depents on where the file located phically.

How to repeat it:
1. Find a slow transfer rate network (sorry, it may be hard)
2. Prepare a long c file, 3-4 screens.
3. take font-lock-mode on (jit-font-mode)
4. Open the c file and scroll down, scroll down, scroll down...
5. scroll up, scroll up, scroll up

I have tried profiler. It indicates, the jit-font and redisplay take
majority of the cpu time.
1. open the c file
2. profiler-start
3. scroll down, scroll down, scroll down...
4. profiler-report

Best Regards,
Shuguang Sun