stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] profiling StumpWM


From: David Bjergaard
Subject: Re: [STUMP] profiling StumpWM
Date: Thu, 27 Mar 2014 12:37:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

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 <address@hidden> 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 <address@hidden> 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 <address@hidden> writes:
>>
>>> Evan <address@hidden> 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
>>>>> <address@hidden> 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
>>>>>> address@hidden
>>>>>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> _______________________________________________
>> Stumpwm-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]