On 6.2.2016. 21:48, Emil Dotchevski wrote:
Another stated concern is that exception handling introduces overhead throughout the program even when exceptions are not being propagated, however such overhead (if any) is limited to function call and exit points. In performance-critical contexts function calls are too expensive with or without the added overhead of exception handling, and the solution is to inline the function. In that case all function call overhead disappears, including the exception handling overhead.
However * this reasoning is only valid (and even then not fully) in synthetic tests/non-real world analysis - i.e. 'my program is the only one on the system' - on a real system, this reasoning is merely the number one licence to produce bloatware as there everything is 'performance critical' - your 'non critical' (i.e. fatter and slower than necessary) code (in addition to contributing to OTA and flash storage costs, IO, fragmentation...) might be loaded and/or executed (or simply occupy the virtual address space) at the same time that another app is trying to "squeeze the most of a user's device" (i.e. running its 'critical' part) * inlining is, in general, a primitve bruteforce solution that can only exacerbate the problem of bloatware (discussed this in more detail relatively recently with Andrey Semashev) * even the very latest MSVC compiler cannot inline functions that contain certain types of EH (even something simple as having a by-value parameter that has a non-trivial destructor)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman