https://bugs.kde.org/show_bug.cgi?id=392031

            Bug ID: 392031
           Summary: UI is regularly lagging with regular micro freezes
           Product: kdev-python
           Version: 5.2.1
          Platform: Appimage
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: Language support
          Assignee: m...@svenbrauch.de
          Reporter: fvi...@gmail.com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to