Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[macOS] Typing has high latency when system is under load #1820

Closed
trishume opened this issue Jul 18, 2017 · 9 comments
Closed

[macOS] Typing has high latency when system is under load #1820

trishume opened this issue Jul 18, 2017 · 9 comments

Comments

@trishume
Copy link

trishume commented Jul 18, 2017

Summary

Under heavy system load on macOS, all other GUI apps remain responsive to typing and interaction, except typing in Sublime which has enormous latency.

My guess for why is that the scheduler is under high pressure and while Cocoa apps process interactions with real time priority in-process, Sublime requires communicating with the plugin host process to handle synchronous on_modified handlers. If this takes a number of context switches proportional to the number of on_modified handlers, then taking time to schedule the plugin host to respond could explain the latency, and why it doesn't appear on an unloaded system.

I've heard macOS has a system for prioritizing threads, including a "real time" priority for UI interaction. Perhaps there is a way to give the plugin host real time priority to help this problem? Or to reduce the number of round trips required for on_modified handlers?

Expected behavior

Typing has imperceptible latency.

Actual behavior

Typing has latency on the order of hundreds of milliseconds, perhaps even 500ms.

Steps to reproduce

  1. Have ~5 plugins with on-modified handlers. I have GitGutter, Default.settings, Dart and SideBarEnhancements. I've had this happen with another Sublime instance that doesn't have the Dart plugin but has others.
  2. Put system under load on all cores. For me this is normally a long multi-core C++ build.
  3. Attempt to type in Sublime.

Environment

  • Operating system and version: macOS Sierra
  • Monitor: 1440p
  • Sublime Text: ST3 build 3141 but it's been like this for years
@rwols
Copy link

rwols commented Jul 18, 2017

Related: #1772

@wbond
Copy link
Member

wbond commented Jul 18, 2017

Does profiling the plugins show that any specific plugin is taking a long time in on modified?

I presume it is the same without any plugins installed?

@trishume
Copy link
Author

@wbond

I wrote a Ruby script to create a ton of contending processes whenever I want: https://gist.github.com/trishume/cfe62cd3c247af51d1e0080db4725021

Now I can reproduce it consistently, if you tell me how to start up a Sublime instance without plugins I can check how it behaves.

The fact that increasing it from 8 to 20 processes trying to burn infinite CPU makes a big difference in latency suggests it is caused by difficulty getting scheduled.

Before I started experimenting with this script the highest total time in my plugin profile was 2s for GitGutter after using this run of Sublime for over a week. Now after typing for a little while with my CPU overloaded all the on_modified plugins have tons of total time:

on_modified:
    GitGutter.modules.events: 16.683s total, mean: 0.000s, max: 0.041s
    Dart.analyzer: 8.816s total, mean: 0.000s, max: 0.020s
    Default.settings: 19.389s total, mean: 0.000s, max: 0.030s
    SideBarEnhancements.Stats: 15.621s total, mean: 0.000s, max: 0.030s
    SideBarEnhancements.SideBar: 14.875s total, mean: 0.000s, max: 0.030s

@randy3k
Copy link

randy3k commented Jul 22, 2017

I reckon you could kill plugin_host by pkill plugin_host. It will make Sublime Text Gui responsive again (though pointless).

@rwols
Copy link

rwols commented Jul 22, 2017

I think a practical (but good imo) solution to this is to release two executables for Sublime: one where the plugin_host is part of the main exe, and a "safe mode" sublime executable (the current situation!) where plugin_host is its own process. I understand this decision was made in order to get stability, but I'd wager not many people encounter a crash while using your run-of-the-mill python plugins.

That said, there's also the possibility to attach a custom function handler for the case when EXC_BAD_ACCESS is sent or some other fatal signal in a plugin. I imagine it's not an easy task to deal with this.

@keith-hall
Copy link
Collaborator

The changelog for build 3142 suggests that ST's responsiveness has been improved while under high CPU load.

@wbond wbond added this to the Build 3142 milestone Jul 27, 2017
@rwols
Copy link

rwols commented Jul 27, 2017

I can confirm I experience no more sluggishness while under heavy load on macOS 10.12 with 3142. Great job!

@trishume
Copy link
Author

Confirmed. I ran my core-burning Ruby script, reproduced the issue, updated Sublime, ran the script again and could no longer reproduce the issue.

Thank you! Now the one scenario I had where Sublime Text was ever slow is fixed! 😄 ✨

@randy3k
Copy link

randy3k commented Jul 27, 2017

It is really life saving.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants