6.0.9.2 Resource Usage

PhilHornby

Senior Member
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:

PhilHornby

Senior Member
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...
 

PhilHornby

Senior Member
Reproducible ...

This
Rich (BB 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!
 
Last edited:

PhilHornby

Senior Member
Serial Terminal buffer

This version gives a more visual clue, as to what's going on with the Serial Terminal:-
Rich (BB 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!)
 

Attachments

Last edited:

Technical

Technical Support
Staff member
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.
 
Top