You'd think this would be faster, but NO!!!!!! [Resolved]
#3
It has to do with how the C++ compiler optimizes code. I'm not an expert on this by any means. In the past it wasn't recommended to call functions repeatedly because C/C++ compilers were less clever about it. Also some programmers preferred to do assembly language "by hand" to try to make it faster despite the "expensive" function calls that had to be made. This code might be even faster if it were written in C++ from scratch and even if it employed the classes.

"Inline" is mentioned many times in the "info gcc" manual, and it looks like no project in C/C++ is acceptable without any option for optimization. With 64-bit processors being way faster than 16-bit (parallel processing FTW), it doesn't seem to matter how many times to call a certain function previously considered inefficient, unless of course it does take longer than a few seconds to execute something. However, optimization has become more important in 32-bit and 64-bit than for 16-bit.

Finally, SCREEN() function was considered inefficient in QuickBASIC because it had to read from video memory. QB64PE has to fake it with memory pools, and although it also has to draw a graphics screen it's not really a problem especially when a lot of people have desktop systems with hot-rod GPU's.

Probably in that case ASC() is the one that is dragging things. It's being called twice while SCREEN() is called three times, but each one does a radically different thing.

EDIT: This gave me an idea: QB64PE doesn't support short-circuit evaluation. I think there should be a compiler option for it. :tu:
Reply


Messages In This Thread
RE: You'd think this would be faster, but NO!!!!!! - by mnrvovrfc - 10-14-2022, 12:21 AM



Users browsing this thread: 14 Guest(s)