How to Restart a Bogged Down Program

[SMcNeill]

Well, I think I discovered the issue. I tried running my program on a newer computer on QB64 version 3.6.0 instead of version 2.0.2 on the older machine and, voila, no more sluggishness after the warp sub.    Here's the sub that was causing issues before . . .

---

SUB warpTravel () '                                                      *** WARP TRAVEL EXECUTABLE LOOP ***

    DIM AS INTEGER speed, warp
    DIM i AS STRING
    DIM warpSound AS LONG
    DIM back2SubSound AS LONG

    speed = 15: warp = 4:
    warpSound = _SNDOPEN("going.wav")
    IF warpSound = 0 THEN SOUND 120, 1 ELSE _SNDLOOP warpSound

    DO UNTIL i = "b" '          escape from warpTravel and back to sublight by hitting back ("b") button - for now
        i = INKEY$
        CLS
        _LIMIT speed
        moveFarStars: drawFarStars '
        moveMidStars: drawMidStars '
        moveNearStars: drawNearStars '
        drawViewScreen
        _DISPLAY '                                                                          *** TEMP USER INPUT ***
        IF i = "p" THEN WHILE INKEY$ = "": WEND '                                          pause
        IF i = "f" AND warp < 8 THEN speed = speed + 3: SOUND 650, .8: warp = warp + 1 '    faster
        IF i = "s" AND warp > 0 THEN speed = speed - 1: SOUND 960, .5: warp = warp - 1 '    slower
        IF i = CHR$(27) THEN SYSTEM
    LOOP '                                                                                  warp value to be used for displaying speed...

    _SNDCLOSE warpSound
    back2SubSound = _SNDOPEN("back2SubLight.wav")
    IF back2SubSound = 0 THEN SOUND 100, 1 ELSE _SNDPLAY back2SubSound '
    _AUTODISPLAY '                                                                          needed for speedy lightening effect
    lightning
    _SNDCLOSE back2SubSound

END SUB '                                                                                  *** END WARP TRAVEL EXE LOOP ***

All bplus and mnrvovrfc were pointing out was the basic futility of trying to help someone blind.  Without sharing the code, how is anyone supposed to know that you're using sound statements?  Is the forum community just supposed to guess like throwing darts in the dark, hoping that they can hit some strange behavior?

The main issue here, as it looks to me, would be in the constant opening and closing of a sound file inside an inner loop, as well as the innate pause that SOUND natively generates.

QB64PE v 3+ has had work done to help load sound files faster, and thus it appears as if by upgrading you've fixed the issue, but you've only minimized it somewhat.  Any time you have to access a file, it takes time to load and unload that file from memory.  Since this sub is constantly calling two sounds over and over, I'd simply make those two global sounds and load them once at the start of my program, and then leave them in memory until my program finished running.

In the main program, I'd have:
DIM SHARE AS LONG warpsound, back2SubSound
warpSound = _SNDOPEN("going.wav")
back2SubSound = _SNDOPEN("back2SubLight.wav")

And then in the sub itself, all you'd need is the soundplay statement, and instead of a _SNDCLOSE at the end, use a _SNDSTOP to simply stop the sound from playing.

---

Second point is the SOUND statement itself.  SOUND, from what I remember from using it waaay back in the day, tends to pause a program until its completion.  
SOUND 100, 1 and SOUND 120, 1 both take 1/18th of a second to start, play, and complete, with the program doing nothing else while they're processing.  Combined, that's 1/10th of a second for a pause if warpsound and back2SubSound can't find the wav files properly.  At most, if this routine is called repeatedly, you'd only run at a limit of about 8-9 loops per second -- depending on if there was anything else inside the subs that it calls which might increase that processing time considerably, or not.

---

Third thing which I'd watch for, that stands out to me, is the endless pause loop.

IF i = "p" THEN WHILE INKEY$ = "": WEND '                                          pause

While INKEY$ = "": WEND   <-- This little snippet is going to use 100% of a CPUs processing power and almost instantly turn the fan on for cooling purposes with the laptop/PC which you're running it on.  It's trying to use ALL your computer's resources to check for a keypress every 0.000000001 seconds, or some such insane rate.

Fix for this?  Add a DELAY into that loop so it doesn't process so recklessly.

IF i = "p" THEN WHILE INKEY$ = "": _DELAY 0.1: WEND '                                          pause

You probably won't notice any change whatsoever in how the program responds, but you sure will notice the difference in how much processing your CPU will be doing on it!