Phoenix Edition v3.1 released!

[Stuart]

I hope that this slow down can be fixed somehow because the program I have uses very short sounds for sound events, but if it ends up costing me 5% of speed loss then the sounds will have to go and not even be available as an option...

Would you be able to give examples of the code that you find to be slower? I'm mostly interested in things like what you do with the sound handles and such. If we can pinpoint what exactly is slower then we could look at making some optimizations to those areas.

There are only 3 sound handles used, and they are all defined once, near the beginning of the program : 

  _DELAY .001: s1& = _SNDOPEN("HIGH.WAV")
  _DELAY .001: s2& = _SNDOPEN("LOW.WAV")
  _DELAY .001: s3& = _SNDOPEN("BAD.WAV")


Throughout the program sounds are called with a command like the following : 

  Hz = 900: GOSUB 5555


The only other place that the older "SOUND" command or the sound handles are used is in the sound subroutine : 

    REM -- (SUBROUTINE) -- Play a sound.
5555 IF snd AND D! > 0 THEN
5556    IF QB64 THEN
          IF Hz = 1000 THEN
              _DELAY .001: IF s1& THEN _SNDPLAY s1&: RETURN

          ELSEIF Hz = 900 THEN
              _DELAY .001: IF s2& THEN _SNDPLAY s2&: RETURN

          ELSEIF Hz = 500 THEN
              _DELAY .001: IF s3& THEN _SNDPLAY s3&: RETURN

          END IF
        END IF
        SOUND Hz, D! + .4 * -(D! = 0)
    END IF
    RETURN


NOTE :  This is an "old style", single module .BAS file which will work in QB64 or QB4.5; that's why the "_DELAY .001" commands are present -- QB4.5 will automatically remove the entire line, and the delays don't really affect QB64 at all.

MORE :  There are NO "_DELAY" commands in any critical program loops -- specifically the MAIN LOOP where all of the math calculations and string comparisons are done.



The rest of the program is rather long -- currently about 90.6 KB in total, and I plan to upload it as soon as I finish adding/changing some REM lines, etc.



Now, with all that being said : 

I could be wrong, but I'm starting to think that the main problem causing the speed reduction is when the program gets to a certain length in size : 

The info below is what I get when compiling with the _older_, v0.8.2 : 

When I compile using -Os the size is 2165 KB -- the run time is  9.8 seconds.
When I compile using -02 the size is 2311 KB -- the run time is 11.1 seconds.


According to the compiler options I found here : 
https://gcc.gnu.org/onlinedocs/gcc/Optim...tions.html

It eventually says this : 

Optimize for size. -Os enables all -O2 optimizations except those that often increase code size:

-falign-functions  -falign-jumps
-falign-labels  -falign-loops
-fprefetch-loop-arrays  -freorder-blocks-algorithm=stc

It also enables -finline-functions, causes the compiler to tune for code size rather than execution speed, and performs further optimizations designed to reduce code size.

---

So, since the older v0.8.2 _also_ runs a little slower when the code size increases, I'm assuming that v3.1.0 is slower simply because of the extra code used to add the new audio backend (which I do like better -- mainly because of the less restrictive license agreement).  It also seems to work just as good, and it does support more file types.

Anyway, I hope that some sort of optimization(s) will still be possible so that just having sounds available won't cause too much of a decrease in program speed.


Thanks for your response @DSMan195276 and in advance for checking into it.