大家看看为什么下面这两条语句的执行时间相差这么多？

x5miao

寻址也是需要时间的

GFree_Wind

g_stTPM[TpmNum].Test++;
g_stTPM[TpmNum].Capture[ChalNum].CapNum++;

——这个很明显是第二个慢啊！
得到数组的某个元素，要取得首地址，然后用偏移，取得该值。
第二个两个数组，你说慢不慢

teclimber

就是自己定义的普通结构体，struct TPM_INFO
{
    IDINT8U Mode[TPM1_CHANNEL_NUM];
    IDINT8U    Overflow;
    IDINT16U    Test;
    struct CAPTURE_INFO Capture[6]
};

struct CAPTURE_INFO
{
    IDINT8U     SaveNum;
    IDINT8U CapNum;
    IDINT8U    DutyCycle;
    IDINT8U     Overflow[3];
    IDINT8U TargetCapNum;
    IDINT16U    TotalCapNum;
    IDINT16U      Freq;
    IDINT16U ChannelVal[3];
};
回复 10# davidfoxhu


   

asuka2001

回复 12# GFree_Wind

编译器应该会做优化，既然是POD，内存布局完全可以在编译期决定，可以直接算出目的地址的！

我做了下实验，结果让我失望了。。。编译器还是老实的一步一步的去做的。。。
也许LZ测试的情况就是因为这个？？？

08048394 <main>:


struct TPM_INFO g_stTPM[128];

int main(void)
{
8048394:        55                           push   %ebp
8048395:        89 e5                        mov    %esp,%ebp
8048397:        56                           push   %esi
8048398:        53                           push   %ebx
8048399:        83 ec 10                     sub    $0x10,%esp
        int TpmNum = 123;
804839c:        c7 45 f0 7b 00 00 00         movl   $0x7b,-0x10(%ebp)
        int ChalNum = 6 - 1;
80483a3:        c7 45 f4 05 00 00 00         movl   $0x5,-0xc(%ebp)

        g_stTPM[TpmNum].Test++;
80483aa:        8b 55 f0                     mov    -0x10(%ebp),%edx
80483ad:        89 d0                        mov    %edx,%eax
80483af:        c1 e0 02                     shl    $0x2,%eax
80483b2:        89 c1                        mov    %eax,%ecx
80483b4:        c1 e1 05                     shl    $0x5,%ecx
80483b7:        01 c8                        add    %ecx,%eax
80483b9:        0f b7 80 b6 96 04 08         movzwl 0x80496b6(%eax),%eax
80483c0:        8d 48 01                     lea    0x1(%eax),%ecx
80483c3:        89 d0                        mov    %edx,%eax
80483c5:        c1 e0 02                     shl    $0x2,%eax
80483c8:        89 c2                        mov    %eax,%edx
80483ca:        c1 e2 05                     shl    $0x5,%edx
80483cd:        01 d0                        add    %edx,%eax
80483cf:        66 89 88 b6 96 04 08         mov    %cx,0x80496b6(%eax)

        g_stTPM[TpmNum].Capture[ChalNum].CapNum++;
80483d6:        8b 4d f0                     mov    -0x10(%ebp),%ecx
80483d9:        8b 55 f4                     mov    -0xc(%ebp),%edx
80483dc:        89 d0                        mov    %edx,%eax
80483de:        c1 e0 03                     shl    $0x3,%eax
80483e1:        01 d0                        add    %edx,%eax
80483e3:        8d 1c 00                     lea    (%eax,%eax,1),%ebx
80483e6:        89 c8                        mov    %ecx,%eax
80483e8:        c1 e0 02                     shl    $0x2,%eax
80483eb:        89 c6                        mov    %eax,%esi
80483ed:        c1 e6 05                     shl    $0x5,%esi
80483f0:        01 f0                        add    %esi,%eax
80483f2:        8d 04 03                     lea    (%ebx,%eax,1),%eax
80483f5:        05 b0 96 04 08               add    $0x80496b0,%eax
80483fa:        0f b6 40 09                  movzbl 0x9(%eax),%eax
80483fe:        8d 58 01                     lea    0x1(%eax),%ebx
8048401:        89 d0                        mov    %edx,%eax
8048403:        c1 e0 03                     shl    $0x3,%eax
8048406:        01 d0                        add    %edx,%eax
8048408:        8d 14 00                     lea    (%eax,%eax,1),%edx
804840b:        89 c8                        mov    %ecx,%eax
804840d:        c1 e0 02                     shl    $0x2,%eax
8048410:        89 c1                        mov    %eax,%ecx
8048412:        c1 e1 05                     shl    $0x5,%ecx
8048415:        01 c8                        add    %ecx,%eax
8048417:        8d 04 02                     lea    (%edx,%eax,1),%eax
804841a:        05 b0 96 04 08               add    $0x80496b0,%eax
804841f:        88 58 09                     mov    %bl,0x9(%eax)
        return 0;
8048422:        b8 00 00 00 00               mov    $0x0,%eax
}

对比下开启了优化 -O1，这回编译器直接操作目的地址：

08048394 <main>:


struct TPM_INFO g_stTPM[128];

int main(void)
{
8048394:        55                           push   %ebp
8048395:        89 e5                        mov    %esp,%ebp
        int TpmNum = 123;
        int ChalNum = 6 - 1;

        g_stTPM[TpmNum].Test++;
8048397:        66 83 05 a2 d5 04 08         addw   $0x1,0x804d5a2
804839e:        01

        g_stTPM[TpmNum].Capture[ChalNum].CapNum++;
804839f:        80 05 ff d5 04 08 01         addb   $0x1,0x804d5ff
        return 0;
}

   

teclimber

看来你用的编译器功能比较强大，我用的那个编译器只能设置开或者关优化，无法指定优化的级别。我测试的时候也是在开着优化的时候测的。后来为了改善效率，不用结构体直接操作了，而是全部改用指针去操作结构体的变量，效率快的多了。回复 14# asuka2001


   

asuka2001

回复 15# teclimber

正因为感觉编译器可以优化成直接操作目的地地址，也就是说都是一条指令的内存访问，所以才无法解释怎么会有几倍的效率差异！

也许是编译器优化做得不够？？？LZ直接反汇编了看看呢！