Re: [STUMP] 0.9.9 Performance Regression

[Francis St-Amour]

David Bjergaard Said:
"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)"

Instead of going one commit by one commit, you should use "git bissect" it should save log2(N) time :D

I won't explain it there tho, there is a lot of information about it on the internets.

2014-11-12 21:01 GMT-05:00 David Bjergaard <address@hidden>:

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
>>

_______________________________________________
Stumpwm-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel