因为我们的大学课程,我在过go 的几个月里一直在用纯C编程.我编写的程序非常小,对资源的要求也很低.因此,和GCC一起编译一直是一个几乎瞬间的过程(在我迄今为止最大的程序上花了40毫秒).

不过最近,我报名参加了一个本地比赛,对于这个比赛,C++显然是常态,所以我开始练习.尽管我的程序仍然非常小(甚至不到0.5kB),但我注意到,用g++编译几乎一直就像0.2秒的停顿,紧随其后的是我习惯于使用GCC的即时编译.

下面是我正在测试的代码:

//#include <bits/stdc++.h> // I commented this out thinking that maybe the problem was due to too many header files being included
#include <iostream>
#include <vector>
#include <algorithm>
#include <climits>

using namespace std; // I know this is kind of a bad practice but I've been told it's recommended in competitions for ease of writing

int mex(vector<int> arr, vector<int> subarr) {
    int min = INT_MAX;

    for (auto i : arr) {
        // If i doesn't exist in subarr
        if (find(subarr.begin(), subarr.end(), i) == subarr.end()) {
            if (i < min) {
                min = i;
            }
        }
    }

    return min;
}

int main () {
    vector<int> a = {0,1,2,3,4,5};
    vector<int> suba = {0, 1,3,4};

    cout << mex(a, suba) << endl;

    return 0;
}

这在240ms内编译. 以下是g++的ftime-report个:

Time variable                                   usr           sys          wall           GGC
 phase setup                        :   0.00 (  0%)   0.00 (  0%)   0.00 (  0%)  1562k (  2%)
 phase parsing                      :   0.16 ( 84%)   0.13 ( 87%)   0.29 ( 85%)    60M ( 83%)
 phase lang. deferred               :   0.01 (  5%)   0.01 (  7%)   0.02 (  6%)  5818k (  8%)
 phase opt and generate             :   0.02 ( 11%)   0.01 (  7%)   0.03 (  9%)  5468k (  7%)
 |name lookup                       :   0.05 ( 26%)   0.02 ( 13%)   0.03 (  9%)  2550k (  3%)
 |overload resolution               :   0.01 (  5%)   0.00 (  0%)   0.02 (  6%)  6891k (  9%)
 callgraph construction             :   0.01 (  5%)   0.00 (  0%)   0.01 (  3%)  1448k (  2%)
 df scan insns                      :   0.01 (  5%)   0.00 (  0%)   0.00 (  0%)  4128  (  0%)
 preprocessing                      :   0.01 (  5%)   0.05 ( 33%)   0.05 ( 15%)  1805k (  2%)
 parser (global)                    :   0.03 ( 16%)   0.02 ( 13%)   0.07 ( 21%)    16M ( 23%)
 parser struct body                 :   0.00 (  0%)   0.03 ( 20%)   0.03 (  9%)    11M ( 15%)
 parser function body               :   0.03 ( 16%)   0.00 (  0%)   0.03 (  9%)  3231k (  4%)
 parser inl. func. body             :   0.01 (  5%)   0.02 ( 13%)   0.01 (  3%)  1474k (  2%)
 parser inl. meth. body             :   0.01 (  5%)   0.00 (  0%)   0.03 (  9%)  5790k (  8%)
 template instantiation             :   0.07 ( 37%)   0.02 ( 13%)   0.08 ( 24%)    19M ( 27%)
 constant expression evaluation     :   0.00 (  0%)   0.00 (  0%)   0.01 (  3%)    85k (  0%)
 expand                             :   0.00 (  0%)   0.01 (  7%)   0.00 (  0%)   367k (  0%)
 integrated RA                      :   0.00 (  0%)   0.00 (  0%)   0.00 (  0%)  2092k (  3%)
 LRA non-specific                   :   0.00 (  0%)   0.00 (  0%)   0.01 (  3%)    14k (  0%)
 symout                             :   0.01 (  5%)   0.00 (  0%)   0.00 (  0%)  6907k (  9%)
 rest of compilation                :   0.00 (  0%)   0.00 (  0%)   0.01 (  3%)   212k (  0%)
 TOTAL                              :   0.19          0.15          0.34           73M

我在Ubuntu 22.04上使用的是GCC和g++11.4.0版本.

这是正常现象吗?G++正常情况下是不是比GCC明显慢?或者我的计算机上存在潜在问题?

推荐答案

是的,根据我的经验,这是很常见的,因为C++有很多功能和更复杂的语法.

如果你的代码不使用任何C++功能,编译时间可能几乎相同,但使用C++引入了更多的判断和逻辑,增加了过程的复杂性.

你可以找到更详细的解释原因here

C++相关问答推荐

海湾合作委员会是否保证大小匹配的访问?

从C函数调用asm函数时生成错误的BLX指令(STM32H753上的gcc)

如何正确地索引C中的 struct 指针数组?

为什么可以通过指向常量int的指针间接地改变整数的值?

为什么在C中二维字符数组会有这样的行为?

警告:C++中数组下标的类型为‘char’[-Wchar-subpts]

减法运算结果的平方的最快方法?

如何知道我是否从非阻塞套接字读取所有内容

为什么net/if.h在ifaddrs.h之前?

为静态库做准备中的奇怪行为

调用mProtection将堆栈上的内存设置为只读,直接导致程序SIGSEGV

进程在写入管道时挂起

如何在下面的C代码中正确管理内存?

为什么此共享库没有预期的依赖项?

C11/C17标准允许编译器清除复合文字内存吗?

收到不兼容的指针类型警告,因为函数的返回不是空*,而是 struct 指针

链表删除 node 错误

如何找出C中分配在堆上的数组的大小?

C 中 struct 体自赋值是否安全?特别是如果一侧是指向 struct 的指针?

int 与 size_t 与 long