[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [STUMP] profiling StumpWM
From: |
Eric Abrahamsen |
Subject: |
Re: [STUMP] profiling StumpWM |
Date: |
Wed, 26 Mar 2014 10:52:16 +0800 |
User-agent: |
Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) |
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
>>
- [STUMP] profiling StumpWM, Eric Abrahamsen, 2014/03/24
- Re: [STUMP] profiling StumpWM, Daimrod, 2014/03/25
- Re: [STUMP] profiling StumpWM, Ivan Kanis, 2014/03/25
- Re: [STUMP] profiling StumpWM, Eric Abrahamsen, 2014/03/25
- Re: [STUMP] profiling StumpWM, Evan, 2014/03/25
- Re: [STUMP] profiling StumpWM, Shawn Betts, 2014/03/25
- Re: [STUMP] profiling StumpWM, Evan, 2014/03/25
- Re: [STUMP] profiling StumpWM,
Eric Abrahamsen <=
- Re: [STUMP] profiling StumpWM, David Bjergaard, 2014/03/26
- Re: [STUMP] profiling StumpWM, Shawn Betts, 2014/03/26
- Re: [STUMP] profiling StumpWM, David Bjergaard, 2014/03/27
- Re: [STUMP] profiling StumpWM, Eric Abrahamsen, 2014/03/28
- Re: [STUMP] profiling StumpWM, Evan, 2014/03/26
- Re: [STUMP] profiling StumpWM, Eric Abrahamsen, 2014/03/26
- Re: [STUMP] profiling StumpWM, Evan, 2014/03/26
- Re: [STUMP] profiling StumpWM, Eric Abrahamsen, 2014/03/27