​ ​ ​ ​ 6.0.9.2 Resource Usage
Results 1 to 5 of 5

Thread: 6.0.9.2 Resource Usage

  1. #1
    Senior Member
    Join Date
    Oct 2013
    Location
    Stockport, UK. On a good day, Cornwall UK
    Posts
    360

    Question 6.0.9.2 Resource Usage

    I have a strange issue with Picaxe Editor 6.0.9.2: the longer the program is left open, the more sluggish it gets - finally reaching a stage where it can no longer keep up with key strokes.
    A restart cures it for a while. The problem seems to occur with 'time' rather than 'usage'; i.e. I can come back to my PC after a long idle period, to find it in that state. It does not die completely; it just gets slower and slower. Actually, if you leave it long enough, it does lock up completely.

    I have not tried to reproduce it with a simpler 'workspace' than I am currently using, so I'm reporting it at this stage, purely because it might illicit some 'me too' responses - I appreciate I have probably not provided enough information to solve it.

    Looking at the PicaxeEditor.exe process in Task Manager (with the symptoms present), I notice the following :

    • Near constant 25+% CPU usage (the PC has a 4core processor - but reducing the no. available to PicaxeEditor doesn't alter the percentage ... (it's not a straight-forward cpu-bound loop, which would give 100% on 1 CPU)
    • It has the largest Working Set of any process on the system @ 510,000K and the largest amount of Physical Memory @ 160,000K
    • It has the largest no. of threads @ 31
    • It has the largest no. of User Objects @ 550
    • It is in the top 10 'GDI Objects' @ 484
    • I/O other is the most startling: 300,000,000 operations, resulting in 6,000,000,000bytes of data (6 GIGA bytes!) - amassed while using 1.5hrs CPU time.


    Using SysInternals Process Explorer, I can see that all the CPU activity is taking place in a single thread (PicaxeEdit+0x3da3d0). The Stack for that thread shows details such as:

    DWrite.dll!DWriteCreateFactory+0x37367

    gdiplus.dll!GdipDrawCachedBitmap+0x7d67

    gdiplus.dll!GdipLoadImageFromStream+0x231f

    mscorwks.dll+0x3060
    mscorwks.dll!CreateHistoryReader+0x107781

    gdiplus.dll!GdipSetStringFormatFlags

    (if that helps at all).

    Please advise a diagnostic strategy
    Last edited by PhilHornby; 19-03-2017 at 06:42. Reason: Correct some factual errors

  2. #2
    Senior Member
    Join Date
    Oct 2013
    Location
    Stockport, UK. On a good day, Cornwall UK
    Posts
    360

    Lightbulb An Update.

    This problem also occurs in 6.0.8.7 (an arbitrary version I had to hand).

    It seems to be related to the use of the Serial Terminal...

    The project I am working on at the moment, implements a Web Server on a 14M2. It writes to a Serial WIFI-UART, using HSerout - which of course is also the Programming/Sertxd pin on the 14M2. The data sent to the WIFI-UART is not inverted and just prints as gibberish on the Serial Terminal. Although it's unreadable, it gives a visual indication that a data transfer has taken place - so I've been leaving it running.

    The Webserver transmits about 5Kbytes of data every two minutes. (It's XML - heading for PRTG)

    Anyway - without the Serial Terminal open, the "I/O other" counts do not change at all...

  3. #3
    Senior Member
    Join Date
    Oct 2013
    Location
    Stockport, UK. On a good day, Cornwall UK
    Posts
    360

    Post Reproducible ...

    This
    Code:
    #picaxe 14m2
    #terminal 4800
    do
          sertxd ("*U")
    loop
    coupled with an AXE027 and a 'standard' download circuit seems to demonstrate the issue quite well!

  4. #4
    Senior Member
    Join Date
    Oct 2013
    Location
    Stockport, UK. On a good day, Cornwall UK
    Posts
    360

    Default Serial Terminal buffer

    This version gives a more visual clue, as to what's going on with the Serial Terminal:-
    Code:
    #picaxe 14m2
    #terminal 4800
    #no_data
    do
          Random W0
          sertxd (#b0,#b1)
    loop
    If you watch the Serial Terminal window, you can see that the update rate rapidly drops. If you continue to use features in the editor, you'll notice that its responsiveness also drops off.

    At one point, I hit "Check Syntax" and got :-


    (In case that image doesn't display - it says "Syntax Check Failed - [X] Compiler has stopped responding - unknown error.")

    Clicking "CLEAR" or "CLOSE PORT" may restore PicaxeEditor responsiveness. Unplugging the AXE027 will probably help too.

    (I think I may have set a new record - my currently running PicaxeEditor.exe has, so far, transferred 195 GIGA bytes (I/O Other), according to Task Manager!)
    Attached Images Attached Images
    Last edited by PhilHornby; 20-03-2017 at 19:14. Reason: (still) sorting out the inline image.

  5. #5
    Technical Support
    Join Date
    Jan 1970
    Location
    Bath,UK
    Posts
    6,402
    Blog Entries
    1

    Default

    The Serial Terminal is designed for displaying short debugging messages, not receipt of hours of debugging XML data. If you use it like this the buffer memory will just grow and grow and the syntax colouring will find it harder and harder to parse the large buffer, particularly if it is garbage to start with. If you want to use it like this we suggest you enable the FF character ($0C) as 'clear' (Settings menu in terminal, Special Control Code Functions) and send this command periodically to clear the serial terminal buffer.
    PICAXE Technical Support

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •