Bug 392031 - UI is regularly lagging with regular micro freezes
Summary: UI is regularly lagging with regular micro freezes
Status: RESOLVED FIXED
Alias: None
Product: kdev-python
Classification: Developer tools
Component: Language support (show other bugs)
Version: 5.2.1
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Sven Brauch
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-18 23:56 UTC by Florent Viard
Modified: 2018-03-20 00:19 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.2.2
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florent Viard 2018-03-18 23:56:27 UTC
I'm using kdevelop 5.2.1 (appimage) on 2 different laptops. One with linux mint, another one with a dell ubuntu recently installed.
In my project and open documents there are not more than 10 .py files.

In both computers I did notice a constant lag/ micro freeze of a few seconds.
Very hard to work in such conditions as it work most of the times, but sometimes  I go to a new line and can experience a 2s freeze with the progress bar at hte bottom right that is stuck in some steps.

Disabling python style checker feature, stopped the issue.
Reproduced with the appimage and with a git master build.

I investigated the code and found a few things that are not great the with python style checker code.

To sum up what I have found:
- Appimage doesn't have the pycodestyle module.
(I guess that this should be added)

- inside pythonparsejob.cpp, there is the background parser main code.
- style checking is called through: eventuallyDoPEP8Checking()
For a reason that I have not found, (maybe the url lock), any delay here, like a sleep(30) will freeze the UI even if it is supposed to be a "background" parsing...

Anyway, 
- Style checking is executed through a call to updateStyleChecking in pythonstylechecking.cpp.
- Inside it, the following mutex is taken: m_mutex
- Normally the mutex will be unlocked when when the "python codestyle.py" process return an output on stdout.
- But, if codestyle.py can't import pycodestyle, it will just put a message on stderr and do nothing else.
- Thus, the m_mutex will never be released.

Later parser threads will also try to call updateStyleChecking but they would not be able to get the m_mutex because it is never released. They will still wait for 1s to try to get it, in the parser thread context. This is 1s sleep that are causing the lag.
Comment 1 Florent Viard 2018-03-19 00:04:37 UTC
Fix for the main issue:
https://phabricator.kde.org/D11474
Comment 2 Francis Herne 2018-03-20 00:08:27 UTC
Git commit 864d2d70965e86b5b6b73ab726b88fa07d064121 by Francis Herne, on behalf of Florent Viard.
Committed on 20/03/2018 at 00:03.
Pushed by flherne into branch '5.2'.

Ensure that codestyle.py always returns something on stdout to unlock m_mutex.

By returning only a "0" size on stdout, pythonstylechecking.cpp will
 see a "reply" and unlock the m_mutex.

This avoids serious UI hangs when the stylechecker is enabled but
 `pycodestyle` is not installed.
Differential Revision: https://phabricator.kde.org/D11474

M  +2    -0    codestyle.py
M  +2    -0    pythonstylechecking.cpp

https://commits.kde.org/kdev-python/864d2d70965e86b5b6b73ab726b88fa07d064121