|
Post by Rod on Apr 23, 2023 6:17:56 GMT -5
I dont think it has much to do with drawing and flush. But to eliminate that possibility you need to start Task Manager and watch what is happening with Liberty's memory pool. Press CtrlAltDel and select Task manager while your program is running. It should start around 5mb of memory or there abouts. What is important is what happens over time. If in an hour the mb used has vastly increased it might point to drawing.
Liberty has a drawing segment, it is initiated immediately on startup, it is always on and working. As soon as you draw anything it is added to this segment and painted to the screen. The screen consumes no memory it is only this segment that consumes memory. Even if you never flush, the initial segment is still growing. Cls, dumps all segments including the current segment, discard dumps the current segment but any segments you have flushed are still in memory. So over a long time scale Cls,repaint,flush is a good strategy. Even if you are using up graphic memory you can get to several hundred mb without issue, so 5mb is tiny.
But, you say the counters race when you regain focus. Why, what has been holding them back. Like drawing, events can stack up and be held in a queue, timer events can stack up if they are not processed. So I still say its program flow and you have something coded that is looping or stalling. But I am not sure about background activity since we mostly deal with active windows. Sorry to say but unless you print exactly where you are getting stuck it will remain a mystery.
I would look at the whole code but it would be pointless really because I would not be able to run and debug it without all the com stuff. So lets see what your memory use is doing.
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 23, 2023 6:52:56 GMT -5
I dont think it has much to do with drawing and flush. But to eliminate that possibility you need to start Task Manager and watch what is happening with Liberty's memory pool. Press CtrlAltDel and select Task manager while your program is running. It should start around 5mb of memory or there abouts. What is important is what happens over time. If in an hour the mb used has vastly increased it might point to drawing. Liberty has a drawing segment, it is initiated immediately on startup, it is always on and working. As soon as you draw anything it is added to this segment and painted to the screen. The screen consumes no memory it is only this segment that consumes memory. Even if you never flush, the initial segment is still growing. Cls, dumps all segments including the current segment, discard dumps the current segment but any segments you have flushed are still in memory. So over a long time scale Cls,repaint,flush is a good strategy. Even if you are using up graphic memory you can get to several hundred mb without issue, so 5mb is tiny. But, you say the counters race when you regain focus. Why, what has been holding them back. Like drawing, events can stack up and be held in a queue, timer events can stack up if they are not processed. So I still say its program flow and you have something coded that is looping or stalling. But I am not sure about background activity since we mostly deal with active windows. Sorry to say but unless you print exactly where you are getting stuck it will remain a mystery. I would look at the whole code but it would be pointless really because I would not be able to run and debug it without all the com stuff. So lets see what your memory use is doing. There's only 1 Liberty Basic process in Task Manager. Currently about 15MiB, oscilates in size a bit. Have restarted my program. L.B. process starts around 7MiB. Slowly, and in a oscillanting fashion, grows up. Exactly as you described.
I could render my COM routine non-functional by skipping the actual Rx / Tx lines. Or give it phantom/phony values. That way you would be able to test it. I'm fully convinced it has to be something with the segments you speak off.
Mr. Rod, if you could be so kind as to take a look into it, I would be greatly appreciated. Been burning what's left of my eyebrowns for the last 7 days with this...
Thank you very much
|
|
|
Post by Rod on Apr 23, 2023 8:30:02 GMT -5
If you can set it to run without com and with dummy values charted I will have a look. If you attach it to an email give it a safe .ext like .txt not .bas rodbird@hotmail.com
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 23, 2023 9:19:52 GMT -5
If you can set it to run without com and with dummy values charted I will have a look. If you attach it to an email give it a safe .ext like .txt not .bas rodbird@hotmail.com Rod,
you will receive a .txt file through this email: nuno_t@sapo.pt
Thank you
|
|
|
Post by Rod on Apr 23, 2023 11:54:20 GMT -5
Ok, that is a lot of drawing. I am not following how you time that drawing. However a couple of things.
Firstly you must choose what is on screen that does not change, now thats a lot of drawing, All of the text all of the lines and most of the charting apart from the actual data lines. This is the background. You need to draw it all ONCE and then issue a named flush command like "flush bak" That creates ONE segment that is your fixed background. When you come to redraw the screen you will issue a "redraw bak" command.
After that a new segment is in play, so you will draw in your variable data and when that is done you will issue another named flush command "flush fore". This variable segment needs deleted before you redraw the variable data again. So the redraw sequence is "delsegment fore", "redraw bak", draw your new data, "flush fore" again. In this way there are only ever two segments in play. Never draw anything after that last "flush fore" until you are ready to repeat the cycle.
Now the timer, you must stay in the sub if you set a timer, so no sub to turn the timer off, you need a sub that encases the timer.
call pause 50
sub pause ms timer ms, [done] wait
[done] timer 0 end sub
is what you need.
If you can work on those concepts lets see where it gets us.
Tell me how you are pacing the main loop, may be obvious but I am not seeing it. What I can see is that if I drop into animate or single step that a lot of drawing actions stack up and I get five or more yellow flashes per chart when I go back to full speed running. So pacing the drawing might be required. Are we just looping and drawing every loop, or is there something pacing it?
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 23, 2023 12:15:32 GMT -5
Ok, that is a lot of drawing. I am not following how you time that drawing.
"Firstly you must choose what is on screen that does not change, now thats a lot of drawing, All of the text all of the lines and most of the charting apart from the actual data lines. This is the background. You need to draw it all ONCE and then issue a named flush command like "flush bak" That creates ONE segment that is your fixed background. When you come to redraw the screen you will issue a "redraw bak" command.
After that a new segment is in play, so you will draw in your variable data and when that is done you will issue another named flush command "flush fore". This variable segment needs deleted before you redraw the variable data again. So the redraw sequence is "delsegment fore", "redraw bak", draw your new data, "flush fore" again. In this way there are only ever two segments in play. Never draw anything after that last "flush fore" until you are ready to repeat the cycle."
I believe I don't have that implemented correctly. Will follow your advice and rewrite it that way
"Now the timer, you must stay in the sub if you set a timer, so no sub to turn the timer off, you need a sub that encases the timer.
call pause 50
sub pause ms timer ms, [done] wait
[done] timer 0 end sub
is what you need.
If you can work on those concepts lets see where it gets us."
Will certainly work on it.
"Tell me how you are pacing the main loop, may be obvious but I am not seeing it. What I can see is that if I drop into animate or single step that a lot of drawing actions stack up and I get five or more yellow flashes per chart when I go back to full speed running. So pacing the drawing might be required. Are we just looping and drawing every loop, or is there something pacing it?"
The yellow flashes are locally paced. They are the COM port routine indicators. Flashes mean there's something being trasmited or received. The timing of those flashes in entirely inside the COM port routine. The exception is the timer() function they use. Is not encased as you recommend above.
Everything else should be drawn/redrawn in another timely manner. One minor screen data update every minute, a major one every hour. Again, the timing routine uses timer() also not encased within the same sub-routine as recommended.
Have a lot to work on. Will let you know how it goes.
Thank you for your helpful advices
|
|
|
Post by Rod on Apr 23, 2023 12:23:05 GMT -5
Where is the minute and hour checked?
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 23, 2023 12:38:00 GMT -5
Look for the label [quit] There's a sequence of 3 "loop until ....." just above That 3rd inner loop is where time$() function is used to check if system clock as advanced or not. Used for the seconds clock display The 2nd inner loop checks minutes The outermost one, hours
|
|
|
Post by Rod on Apr 23, 2023 13:07:26 GMT -5
Yes, I see you get the time but do you actually pause until the time has elapsed or do you just loop and only set the flag if the time has elapsed.
If you are just looping do you curtail the drawing till the flag is set?
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 23, 2023 13:12:02 GMT -5
Yes, the inner most loop is just looping around, doing nothing but checking time$() continuously. No drawing happens until one of the flags is set
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 23, 2023 13:54:24 GMT -5
"Firstly you must choose what is on screen that does not change, now thats a lot of drawing, All of the text all of the lines and most of the charting apart from the actual data lines. This is the background. You need to draw it all ONCE and then issue a named flush command like "flush bak" That creates ONE segment that is your fixed background. When you come to redraw the screen you will issue a "redraw bak" command.
After that a new segment is in play, so you will draw in your variable data and when that is done you will issue another named flush command "flush fore". This variable segment needs deleted before you redraw the variable data again. So the redraw sequence is "delsegment fore", "redraw bak", draw your new data, "flush fore" again. In this way there are only ever two segments in play. Never draw anything after that last "flush fore" until you are ready to repeat the cycle."
Not exactly how things work. There's an initial drawing that can be my "flush bak" BUT the next data update as to be ADDED to the already existing one on screen, so a sequence of:
"delsegment fore" "redraw bak"
Would erase my previous data, which is not acceptable Something like:
draw my new data "flush bak"
Migth work. Will give it a try
|
|
|
Post by Rod on Apr 23, 2023 14:07:25 GMT -5
The thing that is in my mind is that if you just loop you are consuming all of the processor cycles and the system has no chance to breathe or catch up.
Liberty will probably do tens of thousands of those loops while waiting for the time to change. You would probably be better off pacing the loop so that other stuff can get done. As a first step why not count and report the number of times you roll round that loop between time changes.
You need to remember that Windows is not a microprocessor that is single minded. Windows has many other tasks to perform sequentially which your loop will inhibit.
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 23, 2023 14:19:28 GMT -5
Liberty will probably do tens of thousands of those loops while waiting for the time to change. You would probably be better off pacing the loop so that other stuff can get done. As a first step why not count and report the number of times you roll round that loop between time changes. Already did that when trying to debug, with the counters on the loops. somewhere above 135000 per minute or so...
How do I make L.B. "wait for it"? without some sort of loop? (that's how you do it in assembly) Another "timer 1000" command? **************************** EDIT *****************************
Just recheked that counting with newest code modifications. In the vicinity of 320000 cycles a minute... Looking at Task manager, performance tab, CPU is idling at 0~1% without my program. Goes up around 30% when running
|
|
|
Post by Rod on Apr 23, 2023 14:43:15 GMT -5
As a rule of thumb you check at twice the frequency of the expected event. So call pause 500.
The % cpu is flawed because you likely have more than one processor 30% means one of your three cores is 100% occupied.
This is also why you can’t get print logs to work, you are looping way too much, slow the whole thing down then you will get a practical log if there are still problems.
|
|
Nuno
Junior Member
Posts: 64
|
Post by Nuno on Apr 23, 2023 15:01:04 GMT -5
That new timer command certainly did lower the CPU usage to the normal 0~1%
Have implemented my segments managing like this:
Start of program draw lots of stuff . . . #graph, "flush bak"
do loop hours draw some more stuff . . do loop minutes draw some more stuff . . #graph, "flush bak"
do loop seconds new timer=499 here end loop seconds end loop minutes end loop hours
end program
However, Task manager shows that the process still grows. Very slowly now, but steadily. The problem will happen again, just will take a lot longer now. I assumed that the " bak" is the label of the segment that is stored in memory. If I reissue "flush bak" will that not overwrite the old one? Just the amount of new data will cause this increase in process size?
It's a 4 core CPU. One of them was close to 90%, the other somewhere between 20~30%
Thank you
|
|