search

ChrisMoller / edif

A GNU APL extension that allows the use of external editors.
GNU General Public License v3.0
2 stars 1 forks source link

High CPU usage of apl/main while in the edif editor #3

Open Russtopia opened 2 years ago

Russtopia commented 2 years ago

When within the editor spawned by edif to edit a function, the CPU usage seems to spike and stay at max until one saves and exits the edit session.


                    ______ _   __ __  __    ___     ____   __ 
                   / ____// | / // / / /   /   |   / __ \ / / 
                  / / __ /  |/ // / / /   / /| |  / /_/ // /  
                 / /_/ // /|  // /_/ /   / ___ | / ____// /___
                 \____//_/ |_/ \____/   /_/  |_|/_/    /_____/

                  Welcome to GNU APL version 1.8 / SVN: 1496M

                Copyright (C) 2008-2021  Dr. Jürgen Sauermann
                       Banner by FIGlet: www.figlet.org

                This program comes with ABSOLUTELY NO WARRANTY;
                          for details run: apl --gpl.

     This program is free software, and you are welcome to redistribute it
         according to the GNU Public License (GPL) version 3 or later.

SAVED 2021-11-26 21:55:54 (GMT-8)
      'libedif.so' ⎕fx 'edif'
edif
      edif 'beers'

[ enter session, then this is observed in another window via the top util]:

%Cpu(s): 25.9 us,  0.5 sy,  0.0 ni, 73.3 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :  15639.9 total,  11851.6 free,   2081.2 used,   1707.1 buff/cache
MiB Swap:  16584.0 total,  16582.7 free,      1.2 used.  12905.1 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND    
19217 russtop+  20   0   78624  14396  12100 S 300.0   0.1   0:36.30 apl/main   
 5214 russtop+  20   0   16.4g 104948  64164 S   6.3   0.7  49:17.68 vivaldi-b+ 
 5288 russtop+  20   0   24.5g 188596 100844 S   3.7   1.2   4:08.70 vivaldi-b+ 
 6421 russtop+  20   0   28.5g 368984 106116 S   2.0   2.3  33:27.23 vivaldi-b+ 
 3355 root      20   0  728404  80884  65940 S   1.3   0.5   8:55.32 Xorg       
...
...

System Info

BUILDTAG:
---------
    Project:        GNU APL
    Version / SVN:  1.8 / 1410M
    Build Date:     2021-01-19 19:59:14 UTC
    Build OS:       Linux 4.15.0-123-generic x86_64
    config.status:  '--enable-maintainer-mode' 'DEVELOP_WANTED=yes'
    Archive SVN:    1406
$ apl --cfg

configurable options:
---------------------
    ASSERT_LEVEL_WANTED=1 (default)
    SECURITY_LEVEL_WANTED=0 (default)
    APSERVER_PATH=/tmp/GNU-APL/APserver (default)
    APSERVER_PORT=16366 (default)
    APSERVER_TRANSPORT=0 (default)
    CORE_COUNT_WANTED=4
    DYNAMIC_LOG_WANTED=no (default)
    MAX_RANK_WANTED=8 (default)
    RATIONAL_NUMBERS_WANTED=no (default)
    SHORT_VALUE_LENGTH_WANTED=12, therefore:
        sizeof(Value)       : 456 bytes
        sizeof(Cell)        :  24 bytes
        sizeof(Value header): 168 bytes

    VALUE_CHECK_WANTED=no (default)
    VALUE_HISTORY_WANTED=no (default)
    VF_TRACING_WANTED=no (default)
    VISIBLE_MARKERS_WANTED=no (default)

how ./configure was (probably) called:
--------------------------------------
    ./configure  '--with-ctrld_del=y' '--with-gtk3' 'CORE_COUNT_WANTED=4' 'RATIONAL_NUMBERS_WANTED=y'

BUILDTAG:
---------
    Project:        GNU APL
    Version / SVN:  1.8 / 1410M
    Build Date:     2021-01-19 19:59:14 UTC
    Build OS:       Linux 4.15.0-123-generic x86_64
    config.status:  '--enable-maintainer-mode' 'DEVELOP_WANTED=yes'
    Archive SVN:    1406
Russtopia commented 2 years ago

Just looking at the edif.cc source quickly, I didn't find any sleep() or usleep() calls, or select()-like calls to wait on editor file handle; could there be a busy loop somewhere awaiting the editor to return or its file to be closed that might be taking up the CPU?

I didn't really study the logic properly though, so my apologies if this is a red herring.

ChrisMoller commented 2 years ago

No, there's no busy-loop, at least not in my code, but I use inotify to detect when the edited APL file is changed. I haven't a clue what goes on under the covers in that, but it wouldn't surprise me if resulted in a fair amount of kernel arm-waving.

The process spawning, IPC/message-passing, etc, in edif is pretty messy--in a sense I'm having to do a bit of kernel work without being in the kernel.  If you're interested, I've got another APL toy coming out, probably before the end of the year, that provides a cleaner, more flexible, edif-like interface to emacs, gvim, or, likely, whatever.  (The new thing is Qt-based, not an APL native function, and handles processes in Qt's event loop for close to zero additional overhead,)

On 11/27/21 01:30, Russtopia wrote:

Just looking at the |edif.cc| source quickly, I didn't find any sleep() or usleep() calls, or select()-like calls to wait on editor file handle; could there be a busy loop somewhere awaiting the editor to return or its file to be closed that might be taking up the CPU?

I didn't really study the logic properly though, so my apologies if this is a red herring.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ChrisMoller/edif/issues/3#issuecomment-980511481, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM56AJDLVNYTHMVUIUD3Y3UOB3J7ANCNFSM5I32ZFWA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Russtopia commented 2 years ago

Ah.. I am not too familiar with inotify() myself. Sure, I am willing to be a guinea-pig for your other tool!