[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [STUMP] 0.9.9 Performance Regression
From: |
Evan |
Subject: |
Re: [STUMP] 0.9.9 Performance Regression |
Date: |
Wed, 12 Nov 2014 19:33:13 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 |
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
>