Re: [STUMP] profiling StumpWM

David Bjergaard <[email protected]>
Newsgroups gmane.comp.window-managers.stumpwm.devel
Message-ID <[email protected]>
To clarify for myself, paging and using swap (in linux) are the same
thing?  There's the swappiness setting for the linux kernel [1] that you
could use to force programs to prefer swap.  The other thing you could
do is write a c program that allocates almost the entire physical memory
available forcing StumpWM into swap.  

As far as actually profiling, a quick google search dug up the following
links:
http://www-users.cs.umn.edu/~gini/lisp/profile.html
http://john.freml.in/sbcl-optimise-profiling
http://john.freml.in/sbcl-optimise-measure

Cheers,

    Dave

[1] https://en.wikipedia.org/wiki/Swappiness

Shawn Betts <[email protected]> writes:

> If it is a paging issue then the problem is that parts of sbcl are
> being paged in when you hit a key. You can't really plan ahead for a
> sudden key press except to say "never page sbcl to disk" which, if
> such a way exists, is a really ugly hack. It should be easy enough to
> verify: disable swap and see if it gets snappy. Aren't there OS tools
> to tell you when a process gets swapped around? Another way to see
> where the time is being spent is to write a program that uses the
> XTest extension to generate key events. Print the system time at that
> point from the test program and from stumpwm as soon as it gets an
> event and after it's handled.
>
> -Shawn
>
> On Wed, Mar 26, 2014 at 6:35 AM, David Bjergaard <[email protected]> wrote:
>> Hi Eric,
>>
>> If this is really a paging issue (as hinted by Shawn), maybe there's a
>> way to force StumpWM to start swapping. I use SBCL and StumpWM is pretty
>> snappy.  Maybe there's a controlled way to force an application to use
>> swap?
>>
>> Also, if you come up with a profiling procedure I'm happy to try it as
>> well and contribute another data point.
>>
>> Cheers,
>>
>>     Dave
>>
>>
>> Eric Abrahamsen <[email protected]> writes:
>>
>>> Evan <[email protected]> writes:
>>>
>>>> I run SBCL and don't notice this problem in general. If you'd like some
>>>> system stats as a sanity test, or as a way to perhaps rule out some
>>>> things, let me know.
>>>
>>> Please do!
>>>
>>> As I said in the first message, I don't know enough to figure this out
>>> single-handed, but I'm interested in learning. I'd be happy to undertake
>>> exploration, do grunt work, and maintain momentum, but I'd need a bit of
>>> direction from people who know where to look.
>>>
>>> Would the profiling results I linked to in my first message contain any
>>> useful clues?
>>>
>>> Eric
>>>
>>>> Evan
>>>> On 03/25/2014 11:08 AM, Shawn Betts wrote:
>>>>> Hi Eric,
>>>>>
>>>>> I've found the same thing with SBCL, which is why I switched to clisp.
>>>>> If you can discover the issue, that would be amazing. This was all
>>>>> years ago when 256M of ram was "enough". I sort of had a hunch that it
>>>>> was paging related.
>>>>>
>>>>> -Shawn
>>>>>
>>>>> On Tue, Mar 25, 2014 at 2:30 AM, Eric Abrahamsen
>>>>> <[email protected]> wrote:
>>>>>> I'm constantly getting laggy prefix-key detection (I thought it had
>>>>>> gotten better, but it hadn't). I hit "C-t", and then the next keypress
>>>>>> or two goes to the active window, not StumpWM. My girlfriend has already
>>>>>> learned that when I send her "go" in Pidgin, I'm not actually telling
>>>>>> her to go anywhere, I was just trying to switch to the other group.
>>>>>>
>>>>>> Plenty of other commands, particularly frame- and group-related
>>>>>> commands, take a very user-visible chunk of time to execute. Resuming
>>>>>> from hibernation, it can take seven or eight seconds before StumpWM
>>>>>> starts seeing the prefix key.
>>>>>>
>>>>>> I'm quite sure that the problems aren't Stump-only problems, but
>>>>>> something going on with the stump/SBCL on my machine (arch linux, as I
>>>>>> mentioned), but I hope that profiling would help uncover those issues as
>>>>>> well.
>>>>>>
>>>>>> E
>>>>>>
>>>>>> On 03/25/14 16:39 PM, Ivan Kanis wrote:
>>>>>>> March, 25 at 11:50 Eric Abrahamsen wrote:
>>>>>>>
>>>>>>>> I still can't get rid of the idea that Stump is slow, both in reaction
>>>>>>>> to input and in its own operations. I know very little about profiling,
>>>>>>>> but I thought I'd take a whack at it and see if I could learn anything.
>>>>>>>> So far I haven't learned very much.
>>>>>>>
>>>>>>> What kind of slowness? I use it at work and it's snappy.
>>>>>>>
>>>>>>> Ivan
>>>>>>> --
>>>>>>> You must no lose faith in humanity. Humanity is an ocean; if a few
>>>>>>> drops of the ocean are dirty, the ocean does not become dirty.
>>>>>>>     -- Gandhi
>>>>>>
>>>>>> _______________________________________________
>>>>>> Stumpwm-devel mailing list
>>>>>> [email protected]
>>>>>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>>>>>
>>>>> _______________________________________________
>>>>> Stumpwm-devel mailing list
>>>>> [email protected]
>>>>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>>>>>
>>>
>>> _______________________________________________
>>> Stumpwm-devel mailing list
>>> [email protected]
>>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>>
>> _______________________________________________
>> Stumpwm-devel mailing list
>> [email protected]
>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.