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: Wed, 26 Mar 2014 09:35:54 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

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



reply via email to

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