Re: [STUMP] 0.9.9 Performance Regression

[Evan]

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
>