Re: [STUMP] profiling StumpWM

[Eric Abrahamsen]

Evan <address@hidden> writes:

> It looks similarish. I used sbcl-git from aur, commented out the
> customize-target-features.lisp part of the PKGBUILD and added --fancy.
> So maybe that'll fix it...

Aha, good point. I'll try those changes out on the regular 1.1.16 SBCL,
then git SBCL, and see what happens. We really need a proper profiling
test.

Thanks,
E

> Evan
>
> On 03/26/2014 07:55 PM, Eric Abrahamsen wrote:
>> Evan <address@hidden> writes:
>> 
>>>> 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.
>> 
>> Hi Evan,
>> 
>> Thanks for this! I also run arch, and as far as I can tell the above is
>> just the same as the official PKGBUILD, is that right? With the
>> exception of the --fancy flag? Maybe I'll give re-building my sbcl a
>> shot, with the addition of that flag...
>> 
>>> Hope that helps.
>>>
>>> Evan
>>>
>>> On 03/25/2014 09:52 PM, Eric Abrahamsen wrote:
>>>> 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
>>>>>>