Question

I have recently started making a C++ Wrapper of GTK+ (Nothing special, just wrapping everything into C++ classes for easy development, to be used in-house) and to cause minimum performance bloat to the already slow Gtk+ I used inline functions almost everywhere. Take a look at a few class functions…

class Widget : public Object
{
public: // A few sample functions. gwidget is the internal GTK+ widget.
    void Show(void) { gtk_widget_show(GTK_WIDGET(gwidget)); }
    void ShowNow(void) { gtk_widget_show_now(GTK_WIDGET(gwidget)); }
    void Hide(void) { gtk_widget_hide(GTK_WIDGET(gwidget)); }
    void ShowAll(void) { gtk_widget_show_all(GTK_WIDGET(gwidget)); }
public: // the internal Gtk+ widget.
    GtkWidget* gwidget;
};

And although there is an almost non-existent performance bloat and the startup time and memory usage is exactly the same, the file size has increased dramatically. a C Gtk+ sample window generates 6.5 kb while a sample window using my wrapper generates 22.5 kb. , so I need a little advice. Should I continue using inline functions? I want my apps to be efficient and I can compromise a little on file size like I can take it even if a 6.5 kb C GTK+ program generated like 400-500 kb using my wrapper but NOT MORE. I don’t want my wrapper to produce HUGE EXES like wxWidgets or MFC. So is it worthwile to use inline functions or should i use normal ones?

NOTE: all my functions only take up one or sometimes two lines and are not big as you can see in the example.

Answer 1

I strongly suspect you’re comparing apples to oranges.

Did you compiler with exactly the same compiler, the same compile flags, and making an application with the exact same functionality?

If so, disassemble the executable, and see what the extra code is.

My guess is that it’s some one-off library code used to support C++ features that were previously unused.

But as always, don’t guess, measure.

You’ve got a single data point. That doesn’t tell you much.
We could be looking at a 350% increase in file size in all cases, or we could be looking at a fixed 16kb overhead. You need to find out which it is.
So get some more data points. Extend your application. Make it open ten windows instead of one, or otherwise add extra functionality. is “your” version three times as big in that case too? Or is it 16kb larger? Or somewhere in between? Get some more data points, and you’ll be able to see how the file size scales.

But most likely, you’re worrying over nothing, for several reasons:

• the C++ compiler treats inline as a hint. You are making it easy for the compiler to inline the function, but the decision rests with the compiler itself, and it tries to make the application fast. If the file size starts growing out of control, that will slow down your code, and so your compiler will try to optimize more towards a smaller file size.
• you are looking at a couple of kilobytes. In an age of terabyte harddrives. If this has the potential to become a problem, then you should be able to provoke that problem in a test case. If you can’t write a test that causes more than 16kb growth in file size, then it’s not worth worrying about.
• if file size does become a problem, compilers typically have an “optimize for size” flag.
• large executables typically gain their size because they contain a lot of data and resources. The code itself is very rarely the problem (unless you go completely bonkers with template metaprogramming)