一维数组，二维数组指针辩论效率问题

li_rui_1220 2017-10-25 08:32:57

我想优化一下我现在的算法，需要遍历一个30万数据。主要需要优化的代码如下：
数据是存在一维数组中，现在遍历方案如下：
char *pData; //指向30数据
char *pTemp;
LineNum = 640;
for(i =0;i<640;++i)
{
for(t = 0;t<480;++t)
{
pData[t*LineNum];
p[i]; //遍历得到的值
}
}
修改为：
char *pData;
typedef char (*changeP)[640];
changeP pp = (changeP)pData; //将一维数组转换为二维指针形式
for(i=0;i<640;i++)
{
for(t=0;t<480;t++)
{
pp[t][i]; //遍历得到的值
}
}
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
思路描述：
原方案中每次遍历都需要一次乘法，感觉有点浪费时间，转成二维指针就没这个问题了，
不过实际运算后，计算两种方式需要的时间，相差不多啊。

看不懂反汇编，请各位论坛前辈指导一下，万分感谢

...全文

643 12 打赏收藏转发到动态举报

写回复

用AI写文章

12 条回复

切换为时间正序

请发表友善的回复…

发表回复

赵4老师 2017-10-26

打赏
举报

http://edu.csdn.net/course/detail/2516 C语言指针与汇编内存地址-三.数组和二维数组

赵4老师 2017-10-26

打赏
举报

引用 11 楼 li_rui_1220 的回复:

引用 10 楼 zhao4zhong1 的回复:
http://edu.csdn.net/course/detail/2516 C语言指针与汇编内存地址-三.数组和二维数组
付费的。。。

以前是免费的。看来CSDN最近银根吃紧。

li_rui_1220 2017-10-26

打赏
举报

引用 10 楼 zhao4zhong1 的回复:

http://edu.csdn.net/course/detail/2516 C语言指针与汇编内存地址-三.数组和二维数组

付费的。。。

赵4老师 2017-10-25

打赏
举报

无profiler不要谈效率！！尤其在这个云计算、虚拟机、模拟器、CUDA、多核、多级cache、指令流水线、多种存储介质、……满天飞的时代！

paschen 2017-10-25

打赏
举报

写成二维pp[t][i]编译器一样会生成计算地址汇编代码，如果你要完全遍历，可以一边遍历一边递加指针

codedoctor 2017-10-25

打赏
举报

直接这样应该是最快了，省去了编译器寻址的损耗。



	char *pData;                      //指向30w数据
	char *pTemp= pData;
	
	int i = 300000;
	while (i--) {
		*pTemp;
		++pTemp;
	}

自信男孩 2017-10-25

打赏
举报

从你的代码上来看，第二个效率会高些。因为，循环的次数是一样的，第一部分有一个计算的过程（会涉及到读变量t, LineNum并做乘法运算），第二部分再循环次数一样的情况下，只是做了读操作。所以，个人认为是第二个效率会高些

真相重于对错 2017-10-25

打赏
举报

关键是循环。

NoEdUl 2017-10-25

打赏
举报

引用 6 楼 li_rui_1220 的回复:

[quote=引用 4 楼 u012947309 的回复:] ......效率问题一般是讨论需要访问多少次，读写多少次等等。。。你这里循环次数都没变，写成一维还是二维并不影响效率。其实你可以简单粗暴的把二维数组当成一堆首尾相连的一位数组。这样看的话二维数组跟一位数组没有区别。

程序是运行在嵌入式平台上的，计算时间哪怕能够节省1ms也是非常必要的。我原来的方式就是按照一维数组处理的，但是我改完以后发现计算时间基本上没咋变化，可能还慢0.3-0.4ms 我在想是不是二维数组指针遍历，执行的效率不高[/quote] 二维的访问方式多找了一次地址。至于二维多找一次地址和一维多一次乘法运算来算地址，哪一个更快我认为这跟环境有关。如果不是海量数据的话，我认为这种差距不会带来质变。如果需要从数量级上来提升效率的话，我想你可能需要修改数据结构和遍历算法了。

li_rui_1220 2017-10-25