I did try new compiler directives to produce the smallest WinLIFT/GDImage C++ DLL.
PowerBASIC 32-bit GDImage.dll = 360960 Kb
C++ 32-bit GDImage32.dll = 306688 Kb
C++ 64-bit GDImage64.dll = 367616 Kb (almost the same size than the PB 32-bit !!!!, with more features)
PowerBASIC 32-bit WinLIFT.dll = 221696 Kb
C++ 32-bit WinLIFT32.dll = 261120 Kb
C++ 64-bit WinLIFT64.dll = 317440 kb
Could you try them and tell me if they work by you?
(just use them with one of the existing demo, thank you)
In order to produce the smallest code i am using these settings in the C++:
- Full optimization (/Ox)
- Favor small code (/Os)
Because GDImage embeds cursor resources, i wonder if the /Os flag was the main reason of the resulting size reduction.
...
Patrice,
I haven't had a chance to try these yet.
Have you done any performance testing? I have found in some cases smaller size can decrease performance.
James
James--
From my own test i can't see any speed difference with GDImage, and there is a smaller memory saving when using the /Os flag.
I think i shall go for it, however i have some test to do on I5 before, because there is such a big difference between i5 and i7.
...
I think that most of the poor performance of the i5 computer is because of the graphic card (Intel HD4000).
In any case the difference between /Os and /Ot is so subjective that it really hard to say.
I think i will post the two flavors, to let you figure out, with your own material...
Have you tried instrument/run option on the "profile guided optimization" menu? I have seen massive speed gains with this, especially with multithreaded code.
A multithreaded record scan which normally takes 6 seconds, takes about 1 second after optimization.
Kev
No i didn't used the PGO because GDImage is a DLL.
So far i have been playing with the /EHsc exception flag, and found that turning it to No, saves an extra 12Kb into GDImage.dll.
There are so many flags, that it hard to figure what is the best and safer combination to use :-[
In my experience, optimizing for size is very safe with Microsoft's compilers. Optimizing for speed, on the other hand, is something that you want to do a lot of extensive testing with. I've run into some interesting (read: difficult to reproduce and debug) problems when using aggressive speed optimizations.
Edit: I would also caution that "better is the enemy of the good" when it comes do code optimization. You can find yourself going down the rabbit hole, spending hours of time trying squeeze out an extra clock cycle or reduce code size by another KiB, when that time could be much better spent doing something like improving core functionality or adding new features. In other words, while we don't want to ignore optimization, we also shouldn't drive ourselves crazy trying to extract every last drop of blood from the stone.