Re: [STUMP] 0.9.9 Performance Regression

[David Bjergaard]

Hi Evan,

Thanks for the hints! I hope that Jim can provide us some useful
information for debugging this further.  

Jim: Feel free to open an issue on github, its much more likely that I
spend time on this if its on the issue tracker.  I don't mind where we
discuss the details as long as there's a place holder in github. If you
don't have a github account let me know an I'll open one for you.

Cheers,

    Dave


Evan <address@hidden> writes:

> I often use stump + emacsclient + slime. What happens is that I connect
> to stump via slime/swank, and whenever the hang occurs I switch to a
> virtual terminal, attach to the running emacs server (so make sure that
> was running before hand) and then switch the sldb buffer.
>
> On 11/12/2014 06:12 PM, David Bjergaard wrote:
>> Hi Jim,
>> 
>> I have to admit, I've never considered the magnitude of the number of
>> windows your trying to manage when writing code for StumpWM.  That being
>> said I haven't written much of it, so hopefully we can sort things out.
>> 
>> There are two options:
>> 1. Start with the git head and roll back commits until you see the older
>>    behavior. (This could be potentially painful depending on how far
>>    back you have to go and how hard it is to get your 120 windows back
>>    open)
>> 2. Take the 0.9.9 version and replace files that changed a lot with the
>>    0.9.8 version until the problem goes away.  Many of the changes that
>>    were made were incremental and single files specific, but you could
>>    end up with an unbuildable system by just substituting files. Off the
>>    top of my head color.lisp and module.lisp changed the most, there
>>    were also a bunch of bug fixes to fix unhandled crashes but these
>>    were minor and shouldn't have caused a change in how stumpwm listens
>>    for events.
>> 3. (speculating) Find a way to interrupt the stumpwm process when the
>>    hang occurs and get a stack trace that we can debug with.  I'm not
>>    sure how to do this exactly, maybe someone else can comment.
>>    
>> Of course there are the "standard" debugging steps:
>> 1. Make sure this problem is still present with an clean .xinitrc (just
>>    "exec /path/to/stumpwm")
>> 2. Use an empty .stumpwmrc (just to make sure its not code you wrote)
>> 3. Set the debug level high and redirect it to a file
>> 4. Provide us with your linux version/distro, the lisp flavor and
>>    version (sbcl, ecl, clisp)
>> 5. Finally, since the module system is so new, let us know what modules
>>    you are using.  There is a known problem with the truetype font
>>    module that makes stumpwm very sluggish even on moderately old
>>    systems.  
>> 
>> Finally: four monitors, 60 windows?! I can't decide if I'm supremely
>> jealous or very frightened.
>> 
>> Good Luck!
>> 
>>     Dave
>> 
>> 
>> Jim Greenleaf <address@hidden> writes:
>> 
>>> In my excitement about the module architecture, I updated from stumpwm
>>> 0.9.8 to the tagged 0.9.9, and have encountered a performance
>>> regression:
>>>
>>> Frequently, my UI hangs, including mouse movement and text entry into
>>> emacs (the keyboard events don't get queued up, they are simply lost),
>>> and if I have a process monitor open before this occurs, I can briefly
>>> see my Xorg.bin server pinning a CPU in kernel-space, after I start
>>> getting UI output again.
>>>
>>> In terms of things I am doing atypically, I do have 61 windows open (I
>>> had around 120 back in version 0.9.8 with no issues) with 8 actively
>>> displayed at any given time, across four screens.
>>>
>>> What steps do you lot suggest taking to more accurately isolate this
>>> regression?
>>>
>>> ________________________________
>>>
>>> Confidentiality Notice
>>> The information transmitted in this electronic mail (e-mail) is the
>>> property of Belvedere Trading LLC. This e-mail is intended only for
>>> the person or entity to which it is addressed and may contain material
>>> that is confidential, privileged or otherwise protected by law. Any
>>> review, retention, retransmission, dissemination or other use of, or
>>> taking any action in reliance upon, this information by persons or
>>> entities other than the intended recipient is STRICTLY PROHIBITED. If
>>> you received this e-mail in error, please alert the sender by reply
>>> e-mail and then delete this e-mail and any attachments in their
>>> entirety, whether in electronic or hard copy format.
>>>
>>> All messages sent to and from this e-mail address may be monitored as
>>> permitted by applicable law and regulations to ensure compliance with
>>> our internal policies and to protect our business. Emails are not
>>> secure and cannot be guaranteed to be error free as they can be
>>> intercepted, amended, lost or destroyed, or contain viruses. You are
>>> deemed to have accepted these risks if you communicate with us by
>>> email.
>>>
>>> _______________________________________________
>>> Stumpwm-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>> 
>> _______________________________________________
>> Stumpwm-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>>