0.9.9 Performance Regression

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

0.9.9 Performance Regression

Jim Greenleaf
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.9 Performance Regression

Jim Greenleaf-2
1) My apologies about the confidentiality notice; we're still sorting
out our free-software contribution infrastructure.

2) I lost a little clarity in editing: My entire UI hangs, and as far as
I can tell, all keyboard events are lost to all applications, it was
just particularly easy for me to verify this about emacs.


_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.9 Performance Regression

David Bjergaard
In reply to this post by Jim Greenleaf
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 <[hidden email]> 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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.9 Performance Regression

Evan-59
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>
> _______________________________________________
> Stumpwm-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.9 Performance Regression

David Bjergaard
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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>>
>> _______________________________________________
>> Stumpwm-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>>

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>>
>> _______________________________________________
>> Stumpwm-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>>

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel


_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel