Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Hi CPU Usage even at rest
#1
Hello. 

First, I would like to say how much I am enjoying using QB64PE - This is my first post. 

I have installed QB64PE it on a Linux VM but I have noticed that it takes my CPU up beyond 90% even when only the IDE is open and no code is running (the fan screaming lets me know!)

I have included two graphs below. The first with the larger area is QB64PE running a small program and then sitting in the IDE only. 

The second with the smaller area, is the same small program in QB64. 

Is there a known issue I should be aware of? 



[Image: msedge-gy-Pqk3lokl.png]
[Image: bmsedge-gy-Pqk3lokl.png]
Reply
#2
I tried to reproduce this type of behavior with a version of Linux Mint, run via a VMware virtual machine, but I couldn't get it to idle with any real CPU usage.  Is there something specific in the code you're running, which might contribute to the difference?  Does it have several $INCLUDE files?  Rely on several DECLARE LIBRARY calls?  Is it a long set of code, such as the qb64pe.bas file itself?

Usually such issues are nothing more than an endless loop without any sort of limit or delay in them.  They run over and over and over, without pausing to let the CPU share resources with other processes like it should.  The only issue is figuring out *where* in the vast sea of code that is qb64pe, one of these endless loops might be hiding.  Any further details, or test code, which you can share, will help us try to pinpoint exactly what to be digging into for the issue.  Smile
Reply
#3
(01-16-2023, 12:58 PM)SMcNeill Wrote: I tried to reproduce this type of behavior with a version of Linux Mint, run via a VMware virtual machine, but I couldn't get it to idle with any real CPU usage.  Is there something specific in the code you're running, which might contribute to the difference?  Does it have several $INCLUDE files?  Rely on several DECLARE LIBRARY calls?  Is it a long set of code, such as the qb64pe.bas file itself?

Usually such issues are nothing more than an endless loop without any sort of limit or delay in them.  They run over and over and over, without pausing to let the CPU share resources with other processes like it should.  The only issue is figuring out *where* in the vast sea of code that is qb64pe, one of these endless loops might be hiding.  Any further details, or test code, which you can share, will help us try to pinpoint exactly what to be digging into for the issue.  Smile

I am using Mint 21.1 with Cinnamon on a Proxmox Server. 

The VM has 4GB Ram, 64GB SDD, 4 Cores 

Just starting QB64PE takes the CPU up to 70% before loading the .bas file 

The code is below. 

I will try another VM and report back. 

Thx!


Code: (Select All)
Input "Day  : "; d$
Input "Month: "; m$
Input "Year : "; y$
d = Val(d$)
m = Val(m$)
y = Val(y$)
m = (m + 9) Mod 12
y = y - m / 10

weekday = Zeller(d, m, y)

Restore DataDayKey
For X = 1 To 7
    Read dKey$(X)
Next X
Print "Week Day = ", dKey$(weekday)

End



DataDayKey:
Data "Saturday","Sunday","Monday","Tuesday","Wednesday","Thursday","Friday"



Function Zeller (d, m, y)
    Dim t1, t2, t3, t4
    If month < 3 Then
        y = y - 1
        m = m + 12
    End If
    t1 = Int(((m + 1) * 26) / 10)
    t2 = Int(y / 4)
    t3 = Int(y / 100)
    t4 = Int(y / 400)
    Zeller = (d + t1 + y + t2 + 6 * t3 + t4) Mod 7
End Function
Reply
#4
Welcome to the forums. Mis dos centavos.

Virtualization is a really complex business, so much that the Oracle product refused to run on my 10-year-old PC. It doesn't seem to care neither how much RAM is installed. It's recommended to really install Linux Mint or whichever penguin and try again.

Is your processor AMD? Because it seems there are difficulties trying to keep stuff up to date equal to Intel.

It might have to do with Linux kernel as well and other factors. If you insist on virtualization I strongly recommend Fedora or Arch-based OS to test in. IJS, with the equipment you have which could well support a rolling-release distribution.

Quote:I have included two graphs below. The first with the larger area is QB64PE running a small program and then sitting in the IDE only.

The second with the smaller area, is the same small program in QB64.

Did you take the screenshots while one of the "INPUT" statements was being executed in your program? Which is this "QB64" that you mean, the "official" one (v2.1) or the "dot-org" one (last was v2.0.2)?
Reply
#5
(01-16-2023, 03:12 PM)mnrvovrfc Wrote: Welcome to the forums. Mis dos centavos.

Virtualization is a really complex business, so much that the Oracle product refused to run on my 10-year-old PC.  It doesn't seem to care neither how much RAM is installed. It's recommended to really install Linux Mint or whichever penguin and try again.

Is your processor AMD? Because it seems there are difficulties trying to keep stuff up to date equal to Intel.

It might have to do with Linux kernel as well and other factors. If you insist on virtualization I strongly recommend Fedora or Arch-based OS to test in. IJS, with the equipment you have which could well support a rolling-release distribution.

Quote:I have included two graphs below. The first with the larger area is QB64PE running a small program and then sitting in the IDE only.

The second with the smaller area, is the same small program in QB64.

Did you take the screenshots while one of the "INPUT" statements was being executed in your program? Which is this "QB64" that you mean, the "official" one (v2.1) or the "dot-org" one (last was v2.0.2)?

It was the QB64.com version - 2.1 it states on the download page. 

I took the graphs while the IDE was doing nothing other than sitting there with the code in edit mode. It had been run, a few times in fact. But was do nothing in particular at the time. 

I repeated the test on an Ubuntu 22.10 and got the following results - this time I also paid attention to the memory.

On this occasion the CPU ran to about 60% but almost the entire 4GB of ram was used. 

I will try to find the time today to repeat this test on 'real' computers running the same OS's



[Image: msedge-az-CGqcbpgm.png]
Reply
#6
And test it out with our latest PE version as well, if you don't mind.  See if we produce the same issue, or if it might be a change or such which they made to their version which doesn't apply with us.  Wink
Reply
#7
So, I thought I would try a Windows VM first. 

I downloaded the pre-compiled QB64PE 3.5.07 and performed the same test on Windows 10 VM with 4GB Ram, 2 Cores, 64GB SDD.

It held a steady 15% CPU and just over 3.2 GB Ram. When executing the program (Running the bas file) , the CPU would go to 60% and drop back down again as soon as the program exited.

The version on the Linux VMs is 3.5.0 (according to the about) and was built from source on the VMs using the setup_lnx.sh script. 


[Image: msedge-wdg-Ng-Ue-LMl.png]
Reply
#8
(01-17-2023, 12:20 PM)daivdW2 Wrote: It held a steady 15% CPU and just over 3.2 GB Ram. When executing the program (Running the bas file) , the CPU would go to 60% and drop back down again as soon as the program exited.

This is entirely expected from any program entering and exiting, but only that. The fault might be with the task manager trying to measure things while another program is trying to set up (race conditions and other high-technical working stuff).

The problem seems to be that you're also running the web browser, that is a big culprit of performance. If not then why do the filenames of the screenshots begin with "msedge"? If it's possible make sure no other programs are running except QB64PE and the task manager, then try these tests again.
Reply
#9
(01-17-2023, 05:43 PM)mnrvovrfc Wrote:
(01-17-2023, 12:20 PM)daivdW2 Wrote: It held a steady 15% CPU and just over 3.2 GB Ram. When executing the program (Running the bas file) , the CPU would go to 60% and drop back down again as soon as the program exited.

This is entirely expected from any program entering and exiting, but only that. The fault might be with the task manager trying to measure things while another program is trying to set up (race conditions and other high-technical working stuff).

The problem seems to be that you're also running the web browser, that is a big culprit of performance. If not then why do the filenames of the screenshots begin with "msedge"? If it's possible make sure no other programs are running except QB64PE and the task manager, then try these tests again.


There were no web browsers running on the VMs. Only the OS, QB64PE and the RDP Service for remote access to the VM.  The screenshots are labelled by the capture program which is called ShareX. 

ShareX is a tool on my Windows 11 laptop that I use to RDP into the VMs.

ProxMox is a Hypervisor. It runs on my mini server and is the tool used to manage the VMs. It has a Web based admin panel and this is the source of the graphs. 

I have multiple screens so I can work on the VM using RDP to load QB64PE while watching the ProxMox stats.

I hope that makes sense?
Reply
#10
(01-19-2023, 09:45 PM)daivdW2 Wrote: There were no web browsers running on the VMs. Only the OS, QB64PE and the RDP Service for remote access to the VM.  The screenshots are labelled by the capture program which is called ShareX. 

ShareX is a tool on my Windows 11 laptop that I use to RDP into the VMs.

ProxMox is a Hypervisor. It runs on my mini server and is the tool used to manage the VMs. It has a Web based admin panel and this is the source of the graphs. 

I have multiple screens so I can work on the VM using RDP to load QB64PE while watching the ProxMox stats.

I hope that makes sense?

Hi davidW2
May I suggest you try VMware Workstation Player as the VM tool Vs ShareX.
It's free whatever your OS is and would eliminate the load of ProxMox and its connection to your mini server.
You can get it here:VMware Player
Just my two cents.
Cheers.
Fifi
Before to send the arrow of truth, dip the head in a honey pot (Cheyenne saying).
Don't tell my Mom I'm on iMac with macOS, she thinks I work on PC with Windows. Tongue
Reply




Users browsing this thread: 1 Guest(s)