内联函数会导致大小增加多少? [英] How much of an increase in size do inline functions cause?

问题描述

我最近开始制作GTK +的C ++包装器(没什么特别的，只是将所有内容包装到C ++类中以便于轻松开发，可以在内部使用)，并使最低的性能膨胀已经很慢了. > Gtk +我几乎在所有地方都使用内联函数.看看一些类函数...

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;
};

尽管几乎没有性能膨胀，并且启动时间和内存使用情况完全相同，但文件大小却大大增加了. C Gtk + 示例窗口生成 6.5 kb ，而使用包装器的示例窗口生成 22.5 kb.，所以我需要一些建议.我应该继续使用内联函数吗?我希望我的应用程序高效运行，即使我使用包装器生成了 6.5 kb C GTK +程序，也可以在文件大小上做出一些妥协，就像我可以接受一样 强>，但没有更多.我不希望我的包装器产生像wxWidgets或MFC这样的巨大的EXES .那么使用内联函数值得还是我应该使用普通函数?

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.

推荐答案

我强烈怀疑您是在将苹果与橘子进行比较.

I strongly suspect you're comparing apples to oranges.

您使用完全相同的编译器，相同的编译标志以及具有 exact 功能的应用程序进行编译了吗?

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.

我的猜测是，这是一个一次性库代码，用于支持以前未使用的C ++功能.

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.

您只有一个数据点.那并不能告诉你太多. 在 all 情况下，我们可以看到文件大小增加了350％，或者在固定的16kb开销下，我们可以看到文件大小增加了350％.您需要找出它是什么. 因此，获得更多数据点.扩展您的应用程序.使它打开十个窗口，而不是一个，或者添加其他功能.在这种情况下，您的"版本的大小也是三倍吗?还是更大16kb?还是介于两者之间?获取更多数据点，您将可以看到文件大小缩放的方式.

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:

• C ++编译器将内联视为提示.使编译器内联函数变得容易，但是决定权在于编译器本身，并且它试图使应用程序更快.如果文件大小开始失去控制，那将会减慢您的代码速度，因此您的编译器将尝试针对较小的文件大小进行更多优化.
• 您正在查看几个千字节.在 TB 硬盘时代.如果这有可能成为问题，那么您应该能够在测试用例中引发该问题.如果您不能编写一个导致文件大小增长超过16kb的测试，那就不用担心了.
• 如果文件大小 成为问题，则编译器通常会带有优化大小"标志.
• 大型可执行文件通常会增大它们的大小，因为它们包含大量数据和资源.代码本身很少是问题(除非您完全使用模板元编程)

• 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)

这篇关于内联函数会导致大小增加多少?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！