Closed carlos-montiers closed 4 years ago
Performance is not an issue. Timer is a single API call; the first timerhi calls two API functions and does a calculation, other calls are a single API call. There's no performance to optimise. Likewise with other extensions. If you really want high performance stop using CMD. It takes about 100ms just to load EB, so that's a big saving, right there. ;)
I did compile with -Os and x86 crashed; it did work with -fomit-frame-pointer, though. Probably an issue with the inline asm.
I did compile with -Os and x86 crashed; it did work with -fomit-frame-pointer, though. Probably an issue with the inline asm
Is possible detect the real cause?
Probably, but don't you want to use -fomit-frame-pointer? I don't see why I should waste time tracking down a bug that only appears under specific circumstances. Assuming, of course, that's the only bug.
I add #pragma GCC optimize ("Os")
to all c files and using -O3 I get these size and pass all the tests:
x64
66560
x86 62976
Thus with the same trick I change to -Os and interestingly I get this sizes: x64 67,072 (little more)
x86 62976 (equal)
But the x86 not pass the test.
Thus my conclusion is that -Os can doing some wrong thing and also you can get even more less bytes and working code for both platforms using #pragma GCC optimize ("Os")
in each file but optimizing globally as -O3
I have this idea: Optimize some extensions differently for save bytes.
Thus, I think we can save some bytes optimizing with -Os the extensions that are not used frequently, for example the related to get windows version info.
The rest of extensions that need high performance I can also use with -O3 the -fomit-frame-pointer option for get more performance.
Mmm, but maybe we save only a few bytes, for all the work of compile separately. But this idea can be useful for other new extensions