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 <jgreenl...@belvederetrading.com> 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
> Stumpwm-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
_______________________________________________
Stumpwm-devel mailing list
Stumpwm-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
