[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [STUMP] 0.9.9 Performance Regression
From: |
David Bjergaard |
Subject: |
Re: [STUMP] 0.9.9 Performance Regression |
Date: |
Wed, 12 Nov 2014 21:01:31 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
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
>>