Re: [STUMP] profiling StumpWM

Evan <[email protected]>
Newsgroups gmane.comp.window-managers.stumpwm.devel
Message-ID <[email protected]>
> CL-USER> *features*
> (:CLOSER-MOP :SBCL-DEBUG-PRINT-VARIABLE-ALIST :MARSHAL
>  :SBCL+SAFE-STANDARD-READTABLE :NAMED-READTABLES :SWANK :21BIT-CHARS
>  :FLEXI-STREAMS :RUNE-IS-CHARACTER :SPLIT-SEQUENCE CFFI-FEATURES:FLAT-NAMESPACE
>  CFFI-FEATURES:X86-64 CFFI-FEATURES:UNIX :CFFI CFFI-SYS::FLAT-NAMESPACE :CL-FAD
>  :BORDEAUX-THREADS :CL-PPCRE :THREAD-SUPPORT :CLX-EXT-RENDER :CLX-MIT-R5
>  :CLX-MIT-R4 :XLIB :CLX :CLX-LITTLE-ENDIAN :CLX-ANSI-COMMON-LISP :QUICKLISP
>  :SB-BSD-SOCKETS-ADDRINFO :ASDF3 :ASDF2 :ASDF :OS-UNIX :NON-BASE-CHARS-EXIST-P
>  :ASDF-UNICODE :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS
>  :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPARE-AND-SWAP-VOPS
>  :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF :FLOAT-EQL-VOPS :GENCGC
>  :IEEE-FLOATING-POINT :INLINE-CONSTANTS :LARGEFILE :LINKAGE-TABLE :LINUX
>  :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-BLKSIZE-T
>  :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :OS-PROVIDES-GETPROTOBY-R
>  :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T
>  :PACKAGE-LOCAL-NICKNAMES :RAW-INSTANCE-INIT-VOPS :SB-AFTER-XC-CORE
>  :SB-CORE-COMPRESSION :SB-DOC :SB-EVAL :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS
>  :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD :SB-UNICODE
>  :SB-XREF-FOR-INTERNALS :SBCL :STACK-ALLOCATABLE-CLOSURES
>  :STACK-ALLOCATABLE-FIXED-OBJECTS :STACK-ALLOCATABLE-LISTS
>  :STACK-ALLOCATABLE-VECTORS :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS
>  :UNIX :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)
> CL-USER> 

OS: Arch Linux x86_64
Kernel Release: 3.13.6-1-ARCH
Processor Type: Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz

I think that's about it, really. I build sbcl with --fancy. I run the
following command `src/runtime/sbcl --core output/sbcl.core --script
${srcdir}/arch-fixes.lisp` to make my sbcl.core file, and
arch-fixes.lisp is here: http://paste.lisp.org/+31EL
Stumpwm is built without any fancy config flags.

Hope that helps.

Evan

On 03/25/2014 09:52 PM, Eric Abrahamsen wrote:
> 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
>>>
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.