模块化与性能。在C语言里相互矛盾？

[cfvmario]

有一个功能较复杂的模块A，里面有很多数据
现代编程风格么，一个函数写的太大不好，于是按处理步骤拆分出函数B,C等
可是，B,C里需要A里的很多数据
C语言不允许嵌套函数，因此只好把B,C用到的数据全部作为参数传进去调用
可是B,C这样的函数根本就不会在A以外调用，根本就是这种只在一处调用的内部实现函数，那么无端浪费这样的传参数开销是何苦呢？
举例就类似这样的

void A(...)
{
TYPE_X x;
TYPE_Y y;
TYPE_Z z;
....
....
B(&x,&y,&z);
....
C(&x,&y,&z);
....
}
附带说一下，B,C也不是那种极为短小的小函数，inline不可能对编译器起作用的。（再说inline也不是C89标准，跨平台性都无法保证）
为了性能，难道唯一的办法是放弃函数B,C把代码全堆A里么？我不敢这么乱来，怕代码可读性没了。。

[luciferisnotsatan]

能你发现性能瓶颈，而且必须优化时，再去牺牲可读性，可维护性来提高性能。

[qq120848369]

不要过早的优化.

[cfvmario]

事实上和传参数本身的一点开销相比，更大的开销在函数里的指针访问
B要修改x,y,z，只好写成B(TYPE_X*, TYPE_Y*, TYPE_Z*)再B(&x,&y,&z)
然后在B里只能不断的x->x1, x->x2这种
指针一多，问题就来了。编译器总是无法对指针做优化假定（可以理解，因为总怕别的指针也指向它），例如我自己知道前后的几个访问x->x1都是同一个值，但编译器无法知道，每次都要重新间址，Alt+8看到一大堆有些是没有必要的mov, lea，这个开销更大
所以才不可忽视了
（传引用当然是个好方法，可传引用也不符合C89标准……）

[AnYidan]

那就写成一个吧，把相关功能的代码尽量写在一块

[wuwenye]

一直觉得怕函数写太大是很蛋疼的事情。。。

不用inline，我其实更喜欢#include。

[redleaves]

绝大多数情况下,逻辑设计合理,函数划分不会对性能有太大影响.
楼主应该研究一下你代码的逻辑设计

[Enter空格]

[Quote=引用 6 楼 redleaves 的回复:]
绝大多数情况下,逻辑设计合理,函数划分不会对性能有太大影响.
楼主应该研究一下你代码的逻辑设计
[/Quote]

++

要照楼主的意思，C++连写大型程序的资格都没了。