Why is this loop slow in FB?

[Raithe]

So I've been checking FreeBasic out for a few days now. I noticed a lot of the old source I had wouldn't run. So I decided that a quick run thru some examples would point out the differences between QB and FB.

This piece came from David Tordrup's tutorial on Structured Programming.

Code:

FOR Row% = 1 TO 25
  FOR Col% = 1 TO 80
    LOCATE Row%, Col%
    PRINT "."
  NEXT Col%
Next Row%

In QBX it runs almost faster than I can see, but in FB I can count each dot out loud as it appears. Is this an bug in the compiler or is my 500mhz k6 to wimpy for FB .
Thanks,
Jack

[ShadowWolf]

it's not FB it's consol programming print and locate is slow in consol i belive this has already been talked about in a prevouse thread.

[Raithe]

Okay but if its the console print why is it only slow in FB and not QB? Not trying to argue with you, I'm just confused.
I did a search for a similar topic, but nothing relevant popped up.

[ShadowWolf]

look here for the reason why print is slow

http://forum.qbasicnews.com/viewtopic.php?t=7807

[Raithe]

cool thanks for the assist.

[theuserbl]

look here for the reason why print is slow

This explains only why a print of a DOS-program is faster than a print of a Win32 program.

But a printf in MinGW and in lcc-win32 is also a lot of faster than print with fb.

But I don't see that making print faster have a high priority. You can also all do in graphic-mode. And happily the print in the gfxlib is faster then all what I have seen before.

[v3cz0r]

You can't compare FB's PRINT with C's printf(), FB has to check for VIEW PRINT and has to emulate QB's scrolling quirks, what takes no less that 4 calls to the Windows API.

The test below compiled by FB took 3.734 secs on my box:

Code:

tmr# = timer
for i = 0 to 99
FOR Row% = 1 TO 25
    PRINT string$( 80, asc( "." ) );
Next Row%
next i

print timer - tmr#

And this C one took 3.618 secs, compiled with Mingw:

Code:

int main( void )
{
    int i, row;
    int tmr = clock();
    
    for( i = 0; i < 99; i++ )
        for( row = 0; row < 25; row++ )
            printf( "%s", "................................................................................" );
            
    printf( "%g\n", (clock() - tmr) / 1000.0 );

}

Meaning, if you are printing ordinary text, not a single character at time, the difference will be marginal.

The same test compiled by VBDOS took ~7 seconds, if you want to see the *real* console speed for DOS apps, you must switch to full-screen, because in windowed mode Windows will only update the DOS app's result screen n-times every second, while for Windows console apps, it will update every time a single character is written.