-
Oct 29th, 2022, 07:54 PM
#1
Thread Starter
Member
[Compile] About Advanced Optimizations
Hello,
I'm here to ask about advanced optimization options. Is it safe to compile by checking all these options?
Thank you!
-
Oct 29th, 2022, 08:21 PM
#2
Re: [Compile] About Advanced Optimizations
See the note labeled "Warning" and the dialog title that says "Advanced." You can also read the Help this dialog will pull up for you if you click the button.
-
Oct 30th, 2022, 03:51 AM
#3
Re: [Compile] About Advanced Optimizations
Attachment 186100
this is how I have, for many many years.
theres of course "issues" that can happen when u do this.
like, if an "integer" gets a value above what he can handle, it will not crash, but result in glitches.
so its important u create a program that can not do things like that.
-
Oct 30th, 2022, 10:36 AM
#4
Re: [Compile] About Advanced Optimizations
Personally, I'd say that the only one that's completely safe to check is the "Remove Safe Pentium FDIV". IDK, but I doubt there are many (if any) Pentium hardware boxes out there anymore, and this CPU hardware bug has been fixed for many decades.
The other five still have relevance today. We can certainly check them, but we'd better have confidence in our code if we do, and also understand what they mean.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Oct 30th, 2022, 10:47 AM
#5
Re: [Compile] About Advanced Optimizations
Never check any of these for production code.
I prefer all the array bounds checks to remain so out of bounds access to get logged in my error handlers so I can fix these quickly.
Removing arrays bounds checking is like sprinkling your code with a good measure of On Error Resume Nexts which is. . . not smart.
On the other hand if you're processing images as your core business your byte array access will suck big time if there are bounds checks left.
You have to choose which side of safety vs performance each particular project should be compiled to.
Often you might want to have a separate "system" component in your solution with all performance optimizations ON.
cheers,
</wqw>
-
Oct 30th, 2022, 10:51 AM
#6
Re: [Compile] About Advanced Optimizations
Originally Posted by wqweto
Never check any of these for production code.
I prefer all the array bounds checks to remain so out of bounds access to get logged in my error handlers so I can fix these quickly.
Removing arrays bounds checking is like sprinkling your code with a good measure of On Error Resume Nexts which is. . . not smart.
On the other hand if you're processing images as your core business your byte array access will suck big time if there are bounds checks left.
You have to choose which side of safety vs performance each particular project should be compiled to.
Often you might want to have a separate "system" component in your solution with all performance optimizations ON.
cheers,
</wqw>
I've done precisely that in the past. For the vast majority of my code, I leave all of these off (except for the FVID check). However, I've got this "image smoothing" routine that I dynamically use when adjusting certain images, and it was originally running a bit slow to use dynamically.
I stuffed it all into a separate AX.DLL with all those optimizations checked, and it now runs much faster. It really surprised me how much performance boost I got.
And that's another tip: You can set these differently in an ActiveX DLL versus your main project, and still use both.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Oct 31st, 2022, 05:26 AM
#7
Re: [Compile] About Advanced Optimizations
Originally Posted by wqweto
I prefer all the array bounds checks to remain so out of bounds access to get logged in my error handlers
I don't compile with Array-bounds check for 20 years now,
and never ran into any "out of bounds"-errors...
(most of my For-loops are defined 0 to Ubound(Arr) though).
What's happening sometimes is, that I forget to check Array-Initialization (on procedure-entry) -
but this doesn't really have to do with "out of bounds"-mistakes.
So, could you give an example for one such "log-entry" (and how the code was written, to run into such an error)?
I'm really curious.
Olaf
-
Oct 31st, 2022, 05:30 AM
#8
Re: [Compile] About Advanced Optimizations
I always check all the options.
-
Oct 31st, 2022, 05:39 AM
#9
Re: [Compile] About Advanced Optimizations
I can only talk about option 2 and 3 (Array bounds and Integer Overflow):
Since i always code "defensively" i still left them off during developement and testing, just to see if i missed something in my "defense"
But once done, i switched them on.
Last edited by Zvoni; Tomorrow at 31:69 PM.
----------------------------------------------------------------------------------------
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------------------
People call me crazy because i'm jumping out of perfectly fine airplanes.
---------------------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad
-
Oct 31st, 2022, 07:02 AM
#10
Re: [Compile] About Advanced Optimizations
Originally Posted by Schmidt
I don't compile with Array-bounds check for 20 years now,
and never ran into any "out of bounds"-errors...
Heh, you cannot get out of bounds error while compiling with bounds checking off and this is the reason you don't see it logged :-))
Here is a one such log we have gotten with "Subscript out of range"
Code:
Dreem 1.5 Build 2021.12.1 (DreemCm15)
Microsoft Windows Server 2012 R2 Standard 6.3.9600, Intel(R) Xeon(R) CPU E5645 @ 2.40GHz, Intel(R) Xeon(R) CPU E5645 @ 2.40GHz, HP ProLiant DL160 G6 215.99GB, cp1251/cp1251, 595.93/595.95MB, GUI 4787/1859
Logging started on 2021.12.21 14:29:04.649
= 2021.12.21 14:29:04.650 34688 83576 =====================================================
Error: &H9
Description: Subscript out of range
Call stack: [TS06:353] DreemCommon15.cGridExtension(frmStoDocuments.geLnkRows, 44626).Value [get](Column=3)(3434)
GridEX20
PDB call stack: MSVBVM60.DLL!__vbaVarLateMemCallLd + 0x1A
DreemCm15.ocx!mdErrorHandling::pvGetPdbCallstack Line 1028
DreemCm15.ocx!mdErrorHandling::LogError Line 753
DreemCm15.ocx!mdErrorHandling::PopRaiseError Line 629
DreemCm15.ocx!cGridExtension::Value__Get Line 3497
DreemTrd15.ocx!cLinkedDocsExtension::m_oLnkRowsExt_RowColChange Line 4556
OLEAUT32.DLL!DispCallFunc + 0xB0
MSVBVM60.DLL!__vbaAptOffset + 0x68B
MSVBVM60.DLL!BASIC_DISPINTERFACE_GetTypeInfo + 0x2AA
MSVBVM60.DLL!EVENT_SINK_Invoke + 0x50
MSVBVM60.DLL!EbGetHandleOfExecutingProject + 0x2C07
MSVBVM60.DLL!__vbaRaiseEvent + 0x16
OLEAUT32.DLL!DispCallFunc + 0xB0
MSVBVM60.DLL!__vbaAptOffset + 0x68B
MSVBVM60.DLL!BASIC_DISPINTERFACE_GetTypeInfo + 0x2AA
MSVBVM60.DLL!EVENT_SINK_Invoke + 0x50
MSVBVM60.DLL!EbGetHandleOfExecutingProject + 0x2C07
MSVBVM60.DLL!ProcCallEngine + 0x3E5B
MSVBVM60.DLL!ProcCallEngine + 0x5DFD
MSVBVM60.DLL!ProcCallEngine + 0x5DFD
MSVBVM60.DLL!ProcCallEngine + 0x5DFD
MSVBVM60.DLL!ProcCallEngine + 0x5DFD
MSVBVM60.DLL!IID_IVbaHost + 0x236F3
MSVBVM60.DLL!IID_IVbaHost + 0x239F4
MSVBVM60.DLL!IID_IVbaHost + 0x23ADA
MSVBVM60.DLL!IID_IVbaHost + 0x1A57A
MSVBVM60.DLL!Zombie_Release + 0xBB4F
These bugs get logged sporadically and get combed out one by one until diminishing to zero in production and then crop up again with new features implemented.
Not sure exactly what the problem here is exactly but it could be that the code expected the grid control to have 3 columns while it had 2 columns only or similar. Or it could be a bug in the grid control itself which happens sporadically too.
cheers,
</wqw>
-
Nov 1st, 2022, 04:16 AM
#11
Hyperactive Member
Re: [Compile] About Advanced Optimizations
I run production code that is not super performance critical with only "Remove Safe Pentium FDIV" checked. For a small number of projects where I am chasing the best performance I debug as much as I can out of production and then run production also with only "Remove Safe Pentium FDIV" ticked. After some months with no overflow or array out of bounds errors (this one is a killer as un-trapped it trashes memory and cause a crash - eventually) I turn on everything except assume no alias. If I have production problems after this on my own systems I turn them off one at a time until I find the bug. And so it goes on.
I have one project that is particularly performance sensitive (it does packet capture and traffic analysis) and have found better gains in writing special purpose code rather than using MS generic objects for things like dictionary & collection than I get from compiler switches although the array bounds one probably gives the best bang for bug.
-
Nov 1st, 2022, 07:34 AM
#12
Re: [Compile] About Advanced Optimizations
Originally Posted by wqweto
Heh, you cannot get out of bounds error while compiling with bounds checking off and this is the reason you don't see it logged :-))
Here is a one such log we have gotten with "Subscript out of range"
Code:
Dreem 1.5 Build 2021.12.1 (DreemCm15)
Microsoft Windows Server 2012 R2 Standard 6.3.9600, Intel(R) Xeon(R) CPU E5645 @ 2.40GHz, Intel(R) Xeon(R) CPU E5645 @ 2.40GHz, HP ProLiant DL160 G6 215.99GB, cp1251/cp1251, 595.93/595.95MB, GUI 4787/1859
Logging started on 2021.12.21 14:29:04.649
= 2021.12.21 14:29:04.650 34688 83576 =====================================================
Error: &H9
Description: Subscript out of range
Call stack: [TS06:353] DreemCommon15.cGridExtension(frmStoDocuments.geLnkRows, 44626).Value [get](Column=3)(3434)
GridEX20
PDB call stack: MSVBVM60.DLL!__vbaVarLateMemCallLd + 0x1A
DreemCm15.ocx!mdErrorHandling::pvGetPdbCallstack Line 1028
DreemCm15.ocx!mdErrorHandling::LogError Line 753
DreemCm15.ocx!mdErrorHandling::PopRaiseError Line 629
DreemCm15.ocx!cGridExtension::Value__Get Line 3497
DreemTrd15.ocx!cLinkedDocsExtension::m_oLnkRowsExt_RowColChange Line 4556
OLEAUT32.DLL!DispCallFunc + 0xB0
MSVBVM60.DLL!__vbaAptOffset + 0x68B
MSVBVM60.DLL!BASIC_DISPINTERFACE_GetTypeInfo + 0x2AA
MSVBVM60.DLL!EVENT_SINK_Invoke + 0x50
MSVBVM60.DLL!EbGetHandleOfExecutingProject + 0x2C07
MSVBVM60.DLL!__vbaRaiseEvent + 0x16
OLEAUT32.DLL!DispCallFunc + 0xB0
MSVBVM60.DLL!__vbaAptOffset + 0x68B
MSVBVM60.DLL!BASIC_DISPINTERFACE_GetTypeInfo + 0x2AA
MSVBVM60.DLL!EVENT_SINK_Invoke + 0x50
MSVBVM60.DLL!EbGetHandleOfExecutingProject + 0x2C07
MSVBVM60.DLL!ProcCallEngine + 0x3E5B
MSVBVM60.DLL!ProcCallEngine + 0x5DFD
MSVBVM60.DLL!ProcCallEngine + 0x5DFD
MSVBVM60.DLL!ProcCallEngine + 0x5DFD
MSVBVM60.DLL!ProcCallEngine + 0x5DFD
MSVBVM60.DLL!IID_IVbaHost + 0x236F3
MSVBVM60.DLL!IID_IVbaHost + 0x239F4
MSVBVM60.DLL!IID_IVbaHost + 0x23ADA
MSVBVM60.DLL!IID_IVbaHost + 0x1A57A
MSVBVM60.DLL!Zombie_Release + 0xBB4F
These bugs get logged sporadically and get combed out one by one until diminishing to zero in production and then crop up again with new features implemented.
Not sure exactly what the problem here is exactly but it could be that the code expected the grid control to have 3 columns while it had 2 columns only or similar. Or it could be a bug in the grid control itself which happens sporadically too.
Ah... probably one of these cases where a non-virtual Grid-Ctl is used...
... avoidable when a proper DataSource-Class is bound to a virtual Grid-Ctl.
(proper Data-Container-Classes for DataBinding can be ADO- or SQLite-Recordsets, Collections/Dictionaries -
or your own implementation which internally takes care of proper Array-Bounds, always matching the Column-Count).
Such (generic) 2D or 3D DataCountainer-Classes can then be properly tested in an isolated fashion -
and will allow access to the internal Mem-Allocation-Coords only over external MethodCalls -
(which have their own "Bounds-check" - as e.g. an ADO-Rs has, when you try to access a Field-Object via an "out of bounds-index").
Though I understand that it's hard, to introduce such a change into a "historically grown", big App.
Olaf
-
Nov 1st, 2022, 10:55 AM
#13
Re: [Compile] About Advanced Optimizations
Originally Posted by Schmidt
Such (generic) 2D or 3D DataCountainer-Classes can then be properly tested in an isolated fashion -
and will allow access to the internal Mem-Allocation-Coords only over external MethodCalls -
(which have their own "Bounds-check" - as e.g. an ADO-Rs has, when you try to access a Field-Object via an "out of bounds-index").
Manually checking array bounds would incur even higher performance penalty IMO.
Why use this optimization and risk out of bounds access on unguarded arrays but still inflict performance penalty on certain selected data-containers by manually checking if indexes are within bounds?
cheers,
</wqw>
-
Nov 2nd, 2022, 04:25 AM
#14
Re: [Compile] About Advanced Optimizations
Originally Posted by wqweto
Manually checking array bounds would incur even higher performance penalty IMO.
No, leaving out the built-in array-bounds-check usually gives a performance-advantage of factor 3 (in fast inner loops).
And checking the bounds of an "internal Array" manually (in two lines of code - before entering such a "fast inner loop")
is not affecting this "factor 3" at all.
Originally Posted by wqweto
Why use this optimization and risk out of bounds access on unguarded arrays...
Hmm, seems the arrays in your Grid-scenario (as your Err-Message proves) are not really "guarded" at all.
So, proper array-guarding has to be done "manually" in either case (to avoid such bugs)-
and my advice for "efficiently doing that - only once" was:
- to either write your own generic DataContainer-Class (for usage in Binding-scenarios)
- or use existing ones (like ADO- or SQLite-Rs for tabular 2D-Data)
Virtual Grids only need "one fast inner loop" (a loop over the currently visible cells in the current viewport).
And going through "Method-calls" for this relative low amount of cells is not causing any performance-issues.
Perhaps I should have asked for a concrete snippet of code instead, to make myself better understood...
Do you have any such code-example, where you can say that "Array-bounds-checking is needed"?
Olaf
-
Nov 2nd, 2022, 11:06 AM
#15
Re: [Compile] About Advanced Optimizations
Of course you are right this can be implemented better with pre-loop checks etc. I just accept the reality of team development and we compile everything with bounds checks on. Most recent languages have bounds checks implemented for similar reasons I guess.
Refactoring our code to allow compiling without bounds checks has never been brought up as an issue so far and so we keep on using ordinary VB arrays bravely and depend on logging to capture any indexing issues with our code.
cheers,
</wqw>
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|