The formatting really didn’t copy over well.  Read the actual page here: https://github.com/GalenRhodes/LockSpeedTest/blob/master/README.md

-fobjc-arc-exceptions

My current use of this is to test if there was any overhead involved with using the clang -fobjc-arc-exceptions flag to ensure that memory isn’t leaked when exceptions are thrown in Objective-C.

Basically I compiled this test without -fobjc-arc-exceptions and ran it and then compiled it again WITH -fobjc-arc-exceptions and then ran it again. Each time it runs a simple test where it throws an exception with a variable with locality inside a @try {} block is assigned a newly created object. It does this 2,000,000 times and takes an average of the time to complete each loop (total_time / iterations).

#define _ITERATIONS_ ((uint64_t)(2000000))

-(NSUInteger)testARCExceptions {
    NSString   *str      = nil;
    NSUInteger iter      = _ITERATIONS_;
    NSUInteger throwWhen = (iter - 1);

    for(NSUInteger i = 0; i < iter; ++i) {
        @try {
            TestClass *test = nil;
            test = [[TestClass alloc] init];
            str  = [test buildString:i];
            if(i == throwWhen) {
                @throw [NSException exceptionWithName:NSGenericException reason:@"No Reason" userInfo:@{ @"Last String":str }];
            }
            [PGTestMessages addObject:@"--------------------------------------------------------------"];
        }
        @catch(NSException *e) {
            [PGTestMessages addObject:[NSString stringWithFormat:@"Exception: %@; Reason: %@; User Info: %@", e.name, e.reason, e.userInfo]];
        }
    }

    return iter;
}

} return iter; }

The class TestClass is just a very simple class. The important bit is that it logs a message when it is both created and deallocated.

-(instancetype)init {
    self = [super init];

    if(self) {
        _instanceNumber = [[self class] nextInstanceNumber];
        _instanceName   = [NSString stringWithFormat:@"%@:%@", NSStringFromClass([self class]), [[self class] formattedInstanceNumber:self.instanceNumber]];
        [PGTestMessages addObject:[NSString stringWithFormat:@"Instance %@ created.", self.instanceName]];
    }

    return self;
}

-(void)dealloc {
    [PGTestMessages addObject:[NSString stringWithFormat:@"Instance %@ deallocating.", self.instanceName]];
}

Then when the log is printed after the test you can see each instance of the TestClass being created and deallocated. Even better you can see the effect of the -fobjc-arc-exceptions flag at the end of the output.

Without -fobjc-arc-exceptions

"Instance TestClass:1,999,997 created.",
"--------------------------------------------------------------",
"Instance TestClass:1,999,997 deallocating.",
"Instance TestClass:1,999,998 created.",
"--------------------------------------------------------------",
"Instance TestClass:1,999,998 deallocating.",
"Instance TestClass:1,999,999 created.",
"--------------------------------------------------------------",
"Instance TestClass:1,999,999 deallocating.",
"Instance TestClass:2,000,000 created.",
"Exception: NSGenericException; Reason: No Reason; User Info: {\n    \"Last String\" = \"abnegating abnegation abnegations abnegative abnegator abnegators Abner abnerval abnet abneural\";\n}"

With -fobjc-arc-exceptions

"Instance TestClass:1,999,997 created.",
"--------------------------------------------------------------",
"Instance TestClass:1,999,997 deallocating.",
"Instance TestClass:1,999,998 created.",
"--------------------------------------------------------------",
"Instance TestClass:1,999,998 deallocating.",
"Instance TestClass:1,999,999 created.",
"--------------------------------------------------------------",
"Instance TestClass:1,999,999 deallocating.",
"Instance TestClass:2,000,000 created.",
"Instance TestClass:2,000,000 deallocating.",
"Exception: NSGenericException; Reason: No Reason; User Info: {\n    \"Last String\" = \"abnegating abnegation abnegations abnegative abnegator abnegators Abner abnerval abnet abneural\";\n}"

You can see that without the -fobjc-arc-exceptions flag (the first example) the last instance is never deallocated because the exception is thrown. The next example with the -fobjc-arc-exceptions flag clearly shows that code was added to clean up the objects. The line of bars is not printed between the creation and deallocation because the exception was thrown before execution reached that point.

The result? No difference. None. The numbers I’ve generated (running it three times each way and taking the average) show that if there is a difference it’s only by a 140 nanoseconds at best. And, I should point out, that’s a 140 nanosecondsFASTER than without using -fobjc-arc-exceptions!

All of this leads me to wonder why Apple would have chosen to NOT make this the default when building their own Frameworks. Anyone with some deep knowledge care to chime in?

I originally posted this on LikedIn back in June, 2017.

My high school shop teachers use to drill it into me and my fellow students every day. At least once every day I’d hear one of my shop teachers tell someone in the class, “Use the right tool for the job!” Usually this happened just as someone was about to use a screwdriver as a chisel, use some part of anything as a hammer, or attempt to “eye ball” a line on a mechanical drawing without using a T-Square. To this day, anytime I’m about to use a butter knife as a screwdriver I hear one of their voices in the back of my head.

As a software developer I use tools everyday. And I’m always on the lookout for new tools to help make my job writing programs easier, better, faster, and with fewer bugs. Back when I first started writing code there were very few tools available. Writing code involved running a line editor (what’s WYSIWYG?) to edit your source code, then exiting out of the editor (did I remember to save first?) and running the compiler (time to get coffee), then if it compiled successfully (doh!) running the linker, then finally, if the linking process succeeded, running the actual program to test it. If there was a bug (DOH!) then you’d have to go back and start the whole process over again.

All of this started to change in the mid- to late-1980’s when Integrated Development Environments (or IDEs) started emerging. Programs such as the Merlin Assembler and Turbo Pascal that allowed you to edit source files, compile, link, and debug all from the same application. These days we have fabulous IDEs such as the open-source Eclipseand commercial applications like IntelliJ, CLion, AppCode, and Xcode. These IDEs come packed with incredibly useful features like source code syntax highlighting, automatic formatting and indenting, powerful editing, project wide visual search and replace functions, and fantastic refactoring tools such as being able to rename an identifier (variable, function, etc.) in one spot and having it instantly change everywhere it’s used in any file in the project. And thanks to the profiling and static code analysis tools available for Java and C/C++ these IDEs will even show you your mistakes WHILE your making them! Forget a semicolon and they will highlight it in the editor for you right away. I was blown away the first time an IDE highlighted a section of unreachable code even before I noticed it (something I’m usually pretty good at).

In my professional life, however, I’m blown away by a couple of things. First, the number of other developers who are completely unaware of the number of tools available to them (I’ve even met a few who still use notepad to edit HTML and XML files) and, second, the number of companies who are adverse to letting their developers use those tools even if they do know about them. Even the free ones!

You see, one of the other valuable life lessons the shop teachers in high school taught me was to learn all about the tools that we had available to us – even if we thought we’d never use them. One of my teachers would even bring in catalogs and point out interesting tools that you could get to help you do common jobs faster. That was where I first learned that you could buy “jigs” to help you with everything from building window frames to helping you know exactly where to drill the holes for a door handle so that everything lined up properly.

My teachers felt that while it was important for me to learn to do things the “old fashioned way” or the “long way” (like learning proofs in mathematics), in order to be successful and productive in the real world you needed to learn to use tools that would allow you to be faster, safer, and more accurate. Or better yet, as my metal shop teacher did at least once, dream up and build your own tools. After all, if your building houses for a living why not use a jig to put in the door handles and save yourself hours of time. I doubt you’d see a carpenter today building a house with a hammer and a hand saw when they could go out and buy themselves a nail gun and a power saw. My shop teachers where some of the first people in my life to emphasize to me that time really is money.

That’s why it baffles me when I see another programmer who doesn’t seem to know that you can simply hit control+shift+F in Eclipse to reformat and entire source code file (or that well formatted source code is important to begin with) or a company that refuses to even consider their developer’s requests for certain software tools. There have been so many times in my career that I would have loved to use WinMerge to compare a set of files for differences but some of the companies I’ve worked for won’t allow it even though it’s free.

The issue of a developer being unaware of the available tools is a topic for another article I’m working on regarding people who are passionate about their job versus those that are simply “paying the rent.” Look for that article soon.

But the reluctance of companies to invest in or allow the tools is pretty easy to understand if you look at it from the companies point of view. In this day of data breaches, ransomware attacks, and multimillion dollar fines for unlicensed software, companies are very wary to allow anything to be installed on corporate computers that hasn’t been completely vetted for safety. And I can’t say I blame them. But some companies seem to have taken this stance almost to the extreme even to the detriment of their developers who would benefit from having the right tools. Some companies do have some sort of “suggestion box” approach allowing employees to request certain software so that it can at least be considered. Many companies, however, still have a “NO” standard answer preferring their developers to simply “make do.”

There’s also the issue of encouragement. Companies, mostly those that aren’t software companies in the first place but are large enough to have their own IT departments to support them (like retailers, manufactures, banks and other financial companies), don’t always encourage their employees to enhance their skills or if they do it’s only half-hearted at best. Some will offer free online courses thru sites like Lynda.com but employees must do so on their own time and only a few might offer tuition reimbursement. And at the end of the day there’s virtually no impact to the employees if they do or don’t enhance their skills. Good grief, just trying to get a company to change development processes from waterfall to agile is headache. You might as well be asking everyone in the company to spontaneously change religions!

The downside for all of this that the management of companies should consider is best put in terms of a hospital. If they were in need of emergency, life and death medical care, would they want to go to a hospital that was stuck in the 1990’s because they didn’t want to spend money or take the time to consider new equipment and training and instead preferred their doctors and nurses simply “make do” or would they prefer to go to a hospital that had modern up-to-date equipment and staff that was encouraged to be knowledgable in using those tools and looking for new ones?

But, at the end of the day, it’s still about time and money. Management should always be looking for ways to improve efficiency and the right tools, even if you have to spend a little money, will make the right employee faster, better, more accurate, and happier. And that always equals a healthier bottom line.

I’m really bad about posting new stuff in the last few years.  I’m gonna get better about it though.  I promise…..