Archive for August, 2006

C++ inline abuse

I’m not sure what it is about inline that makes people abuse it. Maybe its the assumption that its an easy way to increase performance or that it saves time when writing code. Unfortunately, misusing inline often causes more problems than it solves.

The only legitimate use of inline is to increase performance. If you’re calling a function a lot, and the overhead of the actual function call is a significant portion of the time spent, then inline is appropriate to use. The overhead doesn’t include the actual body of the function, but the prologue and epilogue that set up and tear down the stack. So if you’re trying to increase the performance of a function itself, inlining won’t help you.

For some reason, some people think inlining is a harmless way to get performance increases. That is, just inline whatever you feel like and you’ll obtain a performance boost, with no adverse side effects. If only that were true.

Problem number one with inlining is maintenance. Anytime that you modify an inline function, anyone who even includes that header file has to be recompiled and linked, regardless if they use the inlined function or not. If you’re on a project of any size, that could turn out to be a lot of files. As a result, inlining increases build times, thus lengthening development cycles.

Problem number two is readability. Most engineers realize that well designed classes encapsulate and hide the implementation. In a way, inlining breaks that by showing implementation in the public interface. Hopefully, most well written classes are used (read) more often than they are modified (write). If I’m trying to use your class, I scan the public methods. If you have inlined functions in your public interface, that’s a lot more code that I have to climb over to get the information that I want.

The other part of readability comes in when debugging. I’m not sure why, but when people inline functions they like to put it all on one line, as if the compiler charged per line used. If someone else comes through and tries to debug the inlined function, its impossible. They cannot set a breakpoint where they want, nor can they accurately step through the statements. Personally, this is one of the more aggravating problems of inlining, although its not inherently caused by inlining.

Also, by putting inlines in the header, you separate that part of the implementation from the rest of the implementation. Most people go to the implementation file (.cpp) when they want to figure out how things work. But then they have to start switching between the header and implementation files, if there are inlines.

Problem number three is code size. Don’t forget what inlining actually does. It copies that code into the places where the function would normally be called. In some cases, it doesn’t increase the code size by much. But for large functions or functions that are used all over the place, this can result in a significant increase in the executable size. That means more paging out to disk, and a longer download if you are distributing over the web. That might be fine if you’re getting an actual performance increase.

Of course, this all assumes inlining will get you better performance. Most of the time it won’t. For most accessor functions there is little or no overhead to calling that function. On the PowerPC functions that do not call other functions can operate in the “red zone,” which means they don’t have set up or tear down a stack frame. So there is very little performance increase in that case.

Furthermore, most inlines aren’t called enough times to save any real time. By real time, I mean time the user will actually notice. Remember, inlines only remove the time required to set up and tear down a stack frame. The time to do that usually isn’t that significant unless you’re calling the function thousands of times in a very short interval. If you just call the function fifty times when the user selects a menu item, sorry, no one will notice that its inlined. You are not giving the user any benefits. But you are inconveniencing yourself and other developers.

There does seem to be one popular reason to use inlines that I do not understand. That is, to save the developer time when writing code. Yep, apparently some people can’t be bothered to switch to the implementation file when writing functions, so they will simply inline the function where they declare it. They are not even attempting to use inlines for the purpose they were invented, but do managed to foist all the disadvantages of inlining on the function. It is a lose-lose situation.

Worst of all are virtual inlines. That is, functions that are declared both virtual and inline. I’m not sure how the authors of these functions actually expect these to work. Inline is a suggestion to the compiler, not a command: just because you ask, does not mean you will receive. A compiler cannot inline a virtual function, unless it knows its type is static. e.g.

class Foo {
inline virtual void bar(void) {
std::cout << "hello world" << std::endl;


Foo foo;;

In this case, bar could actually be inlined because the compiler knows what type foo will be at runtime. However, in most cases, virtual functions are used like this:

class Foo {
inline virtual void bar(void) {
std::cout << "hello world" << std::endl;

void CallBar(Foo* foo) {

In this case, the more common case, the compiler can’t inline. foo could be a Foo or any other derived class that overrides bar(). Once again, all the inconveniences of inline, without any of the advantages.

Don’t get me wrong, I’m not trying to say never use inlines. There is a legitimate use for them. You use them when a function is called enough times that the overhead becomes significant.

There are certain guidelines I follow when using inlines.

First, I only use inlines for performance reasons, and only when a performance tool, such as Shark, indicates a problem. Some engineers just start inlining functions in a module when they think that module is slow. That makes no sense.

Think of it this way: when you get a crashing bug, what do you do? Do you start randomly start changing code in the module where you think the crash is happening? Or do you use a debugger to figure out where the crash happens, and only change code after you’ve determined the cause? I think just about everyone uses a debugger to determine the cause first. In the same way, performance problems are just another bug. But instead of using a regular debugger to find the problem, you use a performance debugger, such as Shark, to find the problem. Then you change the code.

Second, when I do use inlines, I don’t put them inside the class declaration, but at the bottom of the header file. Like so:

class Foo {
inline void bar(void);

inline void Foo::bar(void) {
std::cout << "hello world" << std::endl;

That way, the implementation is inlined, but out of the way so the public interface is easier to read.

Third, I try to determine if I can change my algorithm to simply not call the function as often. It is frequently a more drastic change to make, but it also frequently is a more drastic performance increase than a simple inline.

In the end, inlining can get you performance increases. Just not as often as most people think, and not without some complications.

A day in the life of a software engineer

For those of you who actually read this blog for the articles (as opposed to the pictures), you’ve probably often wondered: what is it, exactly, that you do? Other than make a fool of yourself? In order to answer that question, and have something to do, I present what my daily schedule is like.

8am –Wake up, scratch self, turn over, fall back to sleep. No respectable software engineer gets up this early.

8:15am –MacBook Pro’s dancing in my head. Unless you’re my girlfriend, in which case, I only dream about you baby.

9am –Wake up and realize I do not own a MacBook Pro. My dreams crushed, I see no reason to remain conscious, so I scratch myself, turn over, and fall back to sleep.

9:30am –Apartment maintenance personnel decide that I have slept long enough and begin pile-driving two feet outside my bedroom window, where in the alley they have apparently decided to construct a large shopping center.

9:31am –Contemplate the needed trajectory of a rock that would injure, but not kill, said maintenance person. I might need my ice maker fixed at some point.

9:35am –Give up on plan to maim maintenance personnel because it would involve moving a part of my body, and, let’s me honest, who doesn’t want an large 24-hour supermarket directly outside their window?

10am –Unsure if I am yet awake, maintenance personnel begin mowing what’s left of the grass outside my bedroom with a bush-hog machine.

10:01am –Stagger the 10 feet from my bedroom to my “office.” Manage to stub my toe on no fewer than seven objects. As required by law, at least three are more dense than depleted Uranium.

10:02am –My now semi-awake brain discovers that the computer/printer combo doesn’t not provide this “food” that the Wizard needs, badly.

10:03am –Stagger over to the refrigerator. My agile feet know the path well, and manage to run into the same seven objects.

10:05am –Think about how good a breakfast with scrambled eggs, bacon, and blueberry pancakes would taste. Unfortunately, I am a bachelor so anything that cannot be made from hot-dogs and month old bread is out of the question.

10:06am –With hot-dog flavored “PopTart” in hand, return to the computer.

10:07am –Digg and Slashdot.

11:03am –Decide to actually “work.”

11:04am –Start pulling down code to work on with Perforce, the Fast Software Configuration Management System. The file set consists of three small text files, one resource file, and a large image file describing how the software system works, assuming they had actually built it that way.

12pm –Lunch, which is a hot dog, stale bread, or some combination thereof.

1pm –Perforce, the Fast Software Configuration Management System, actually completes the synchronize operation, leaving me with three small text files, twenty corrupted resource files, and someone’s half eaten pimento cheese sandwich.

1:01pm –Consult Digg and Slashdot, while contemplating why anyone uses Perforce.

2:00pm –Remember that people use Perforce because the alternatives are worse. For example, Visual SourceSafe is a service by Microsoft in which they send a salesman to your place of business to kick you in the seat of your pants repeatedly. In the Professional version of SourceSafe, the salesman also steals your credit card and purchases a site license for Microsoft Money.

2:01pm –Attempt to log into the client’s bug database, so I know what to work on. Discover that I do not have access to bugbase, which is on the internal network, because I did not file a business case for why I need it, three years in advance.

2:05pm –Call the client’s IT department, explain that I need network access from my Mac. To avoid getting the wrong software, keep mentioning that I am using a Mac during any awkward silences and anyplace in the conversation a normal person might say something like “hello.” Sensing my urgency, IT promptly sends me five copies of the Windows software.

2:10pm –Call IT department back to explain that need Mac software, to which I am promptly told “We do not support Windows 98.”

2:15pm –Finally reach the one Mac IT person, whom they apparently keep locked in a cage in the basement, and feed old PowerTalk documentation. He cannot send the software via email because of the 32 byte email attachment limit, but he is able to smuggle out a CD of the software, on the back of one of the many fruit bats in his cage.

2:30pm –Discover that VPN software does not reliably connect to client’s network, but does, in fact, waste a large amount of space on my hard drive and not uninstall.

2:31pm –Call IT department again to explain VPN software does not work. IT carefully explains that I must either rewire my apartment, reconfigure my router so that it is solely and permanently connected to their network, or move to California and/or India for VPN to ever work. They are not sure which. Smoke signals are suggested in the interim.

2:45pm –Randomly change settings in the VPN configuration until I can actually connect to the internal network. Discover that although I can connect, I have no security access to any servers on their network, including the bug database. Furthermore, IT has decided that, for reasons of productivity, anyone connected through VPN should not be able to access anything outside their network, such as, for example, the computer sitting right in front of me.

2:56pm –Call IT department to be granted access to the bug database. The IT person that I reach calmly explains that, yes, he can grant me those privileges, but won’t, because he strongly suspects that will allow me to do actual work.

3:03pm –Have my contact within the client company call IT and explain that its OK for me to do work because I do not work in IT.

3:30pm –Feel smug about getting to bill client for all the time IT wasted.

3:31pm –To celebrate victory over IT, Digg and Slashdot.

3:52pm –Examine the first bug I am supposed to fix, which is marked as “severe” and a “crasher.” It states: “When I press Command-Q, the application quits.” I spend the next hour on the phone explain why that is expected behavior. The phone call ends with the quote “Well, that’s stupid and Apple should change it.”

4:52pm –Digg and Slashdot.

5:23pm –Examine the next bug I am supposed to fix. Although it is simply a misspelled word that has been in the software for seven years, it has now become “urgent,” “must fix,” and, “severe.” Oddly enough, the bug was entered by a technical writer.

5:33pm –Open up Xcode, Apple’s integrated development environment, specially designed for the Mac user who has lost the will to live.

5:38pm –Change the resource string to fix the misspelling, which the previous engineer was unable to do, because, apparently, he could not locate the second button on his Macintosh mouse.

5:50pm –UI designer notices that I fixed the misspelling, and suggests other improvements to the wording, such as rewriting the host operating system from scratch to use more color gradients.

6:04pm –While muttering under my breath about out of control UI designers, Digg and Slashdot.

6:45pm –Examine the next bug, which is from a customer, requesting that we add support for XML file formats and the ability to shave an enraged badger. After serious consideration, I decide to defer the bug for next time.

7:02pm –Receive call from marketing demanding to know why XML files/badger-shaving feature was deferred. They cite numerous customer anecdotes in which they needed the portability of an XML file combined with the ability to shave an angry badger. Most cases involve alcohol, in which the badger had consumed prodigious amounts.

7:30pm –Look at code for the first time today.

7:47pm –Marketing calls back saying what the customer probably, really, honestly, truly needed was a way sober up the badger. They swear the badger is a nice guy, but only acts that way when he’s drunk. Plus he has a bad 5 o’clock shadow.

8pm –Receive call from potential client, asking if we could port his Word processor for Windows to the Mac for twenty nine cents and a large portion on his company’s stock, currently held in a gum-ball machine.

8:28pm –Starving, I crawl to the refrigerator, where I discover a veritable treasure trove of food, in the form of Cheerios, underneath the fridge.

9:02pm –Realizing I am spending too much time reading Digg and Slashdot, I go read Dilbert, Get Fuzzy, and Pearls before Swine.

9:18pm –Return to code and marvel at the fact the compiler has not openly mocked the code in iambic pentameter or simply refused to compile it out of principle.

10:07pm –Digg and Slashdot.

10:41pm –iChat with business parter in which we ridicule Xcode’s speed, code quality, and inability to shave an enraged badger who’s had a few too many drinks.

11:11pm –Notice that the auto-complete in Xcode is actually recommending other, more reputable companies I could be working for.

11:38pm –Digg.

12:06pm –Slashdot.

12:49am –Change egregious code “if ( foo ) doFoo();” to the much more sane “if ( foo ) { doFoo(); }”, on the initial thought that I get paid by the character.

1:22am –Discover the entire Xcode help file is one page that recommends using a better IDE, such as MPW.

1:30am –Change the completely erroneous “if ( foo ) { doFoo(); }” to the actually readable “if (foo) {doFoo();}”. Note the bytes saved by the removed whitespace on my accomplishments.

1:40am –In an attempt to find a snippet of code in my project, Xcode inadvertently finds life on Mars. Still unable to search an arbitrary directory in less than ten steps.

1:44am –Change “if (foo) {doFoo();}” to “if ( foo ) doFoo();”, and wonder what fool added the unnecessary braces and removed the spaces.

1:54am –Against doctor’s orders, read old copies of Inside Macintosh, Volume 1 until I fall asleep. He recommended a large mallet to the head, for the reason that it is less likely to cause severe brain trauma.

As you can see, the life of an independent software engineer is not for the faint of heart. No doubt you have more respect for me now than you have ever had before.

The sordid tale of mm_menu/fw_menu.js

Recently I came to the conclusion that I should write about JavaScript menus. Why? Well, the other day I was searching for my name in Google and noticed that the top hits, and most of the hits, were related to mm_menu.js and fw_menu.js. Now I know its bad form to Google for your own name, but trust me, I was provoked. I noticed in my local blog searches people were searching for menu and mm_menu, despite the fact that I have never written about them on this blog. So why were people looking for them here? It turns out the very top of the mm_menu.js file has this:

* mm_menu 20MAR2002 Version 6.0
* Andy Finnell, March 2002
* Copyright © 2000-2002 Macromedia, Inc.

Ah, in those days I was young and foolish. Foolish enough to leave an electronic paper trail back to me. You don’t see me making that mistake again.

I ended up looking at a lot of the sites that referenced mm_menu or fw_menu. They are typically web developer forums. Most the conversations on said forums go like this:

Newbie: I’ve got these mm_menu.js menus, and I want to them to scroll/delay showing/be horizontal/play the harmonica.

Expert (usually Murray): Those menus suck, don’t use them.

Newbie: But I have most of it working already. I don’t want to start over again.

Expert/Murray: Curse you Marcodobia!

The conversation usually goes downhill from there. There’s also the misunderstanding that I own those menus or even created them. One poster suggested that they take up a collection and pay me to add more features. Ha ha! Dude, I like the idea of you giving me money, but not the idea of me coming within ten miles of the menu code.

How did I get involved with this if I’m not the creator of this mess, you ask? *sigh* Well, if you insist on asking me that question, I guess I have answer it.

I was tricked into it, like most things. I had just started on the Fireworks team at Macromedia when they were trying to push out Fireworks 4.0.2, a bugfix release. The JavaScript menu feature had been released in the 4.0 release, and they had a serious bug already. This would have been a warning sign to anyone with experience, but not me. My boss innocently said, “Say Andy, we’ve got this one simple bug in the menus code. Could you take a look at it?” Not realizing that was manager code for “Run! Run like the wind!” I said “Sure” and went to work. It was a bug in Internet Explorer. A bug that started my hate-affair with IE. I managed to get a work around in that didn’t bloat the code too much more than the already 20k it was at. I thought that was the last I’d have to deal with that code. But no. Through the scientific process of “you touched it last, you own it” I now had to maintain it for the rest of my career at Macromedia.

You see, I didn’t even create this mess. It all started with some dude over at Netscape named “Gary.” (Most likely a pseudonym. He probably had enough sense not to leave his real name on anything.) He wrote this JavaScript library that allowed menus to be created on the fly in Netscape 4. Yep. Netscape 4. As the legend goes, towards the end of the Fireworks 4 development cycle, someone decided JavaScript menus would be a great feature for Fireworks, a graphics program, to have. The engineer tasked with this feature didn’t have time to write such a thing himself, so he searched for something to start from. As fate would have it, he found “Gary”‘s JavaScript menus. Noticing that the JavaScript file wasn’t near bloated enough, the engineer added support for Internet Explorer and the then alleged Netscape 6. He managed to get it up to 25 kilobytes. Take that you 14.4kbps modem users.

For reasons now obvious, that engineer quickly fled the company and the state soon after the Fireworks 4 release.

Which left naive little me to deal with them. The next version of Fireworks, MX (Yeah, I know that’s not a version number, but tell it to the marketing guys. They have trouble with numbers vs letters.), was supposed to have many improvements to our hit feature, the JavaScript menus. By “hit feature”, I mean everyone loved them until they figured out how badly they sucked. Fortunately for us, you can’t try out a feature when the CD is still in the box.

Learning how the menus even worked was a huge pain the backside. It was a lot of non-obvious, uncommented code. But I figured it out and added all the features management claimed we needed, and managed to bloat the code by 5k. It was also during this time I realized what a mess it was, and how badly we needed to scrap it and start all over again. I also helped tech support and customers out by telling them how to hack the code to add features we weren’t going to add directly. This was a mistake because, once again, I used my real name.

When we released MX, the customers marveled at how much code I managed to add without really improving anything. The experts complained because the menus were still huge, slow, inaccessible, un-crawlable, and didn’t work if the user had JavaScript turned off. The newbies complained because although all the new features were nice, they just needed one more feature before they were happy.

Al Sparber just laughed his way to the bank. (He sells competing HTML menus.)

For the next release there were murmuring of adding even more features. That’s when I pulled the engineer trump card and told them that new features couldn’t be implemented unless the menus were rewritten. That thoroughly killed menu work for the MX 2004 release. I began internally campaigning to have a new set of HTML/CSS menus created (there were lots of examples of these popping up externally).

There was a lot of internal movement between the MX 2004 and 8 release of Fireworks. I used that time to write a new version of the menus using HTML and CSS with a little bit of JavaScript. I cleverly substituted bloated JavaScript for bloated CSS. heh heh. That’ll show those experts. This was about the time I got moved off to Dreamweaver, and my good friend Mike ended up finishing up the feature (after it was killed, then brought back, then killed again, went on tour with the Stones, then finally revived.).

On the Dreamweaver side, we astutely decided not to support these new fangled menus, but still allowed the old kind to be created. This, of course, was heralded as a “Great Idea” by our advisors. No, just kidding, they hated it and called us names. Being the agile company that we were, we quickly had lots of emergency meetings and promptly decided not to do anything. That’s how Dreamweaver 8 shipped.

After Dreamweaver 8 shipped I left the company, and my involvement with those accursed menus ended.

Of course, none of this helps those of you suckered into using these menus. So for your benefit, I’ll now tell you how to fix the mm_menu.js. Follow these simple instructions:

  1. Acquire one (1) shotgun. Loaded, preferably.
  2. Acquire one (1) shovel.
  3. Pump mm_menu.js full of buckshot until you feel better.
  4. Repeat Step 3 as necessary or desired.
  5. With the shovel, dig a hole.
  6. Dump the remains of mm_menu.js into the hole.

If you’re confused on how to shoot an electronic file, I would suggest printing it out and shooting the printout. Sure, you could shoot the real thing off the hard drive, but you might have trouble determining if you hit the actual sectors the file resides on. Also, there might be economic and/or legal repercussions if you shot the hard drive.

So don’t use mm_menu or fw_menu. Go find one of the many HTML/CSS menus that are out there. Some are even free. You could even go buy one off Al Sparber. Tell him I sent you. For the number of people I’ve driven to his door by agreeing to maintain the JavaScript menus, he ought to give you some sort of discount.

Or perhaps he would just laugh maniacally at you and double the price.