一行函数调用太多 [英] Too many one line function calls

查看:79
本文介绍了一行函数调用太多的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Ppl,

想要对如下所示的函数调用有意见

如下:

函数funcA(struct A * st_A,struct B * st_B)

{

st_A-> a = st_B-> a


}

基本上这是一个很好的编程习惯,有这样的函数


特别是当我们可以访问调用

程序中的两个结构时???

我想知道这些电话的优缺点是什么?

这样的电话是否会通过加载和卸载来影响执行速度
堆栈????

Plz请记住我在古老的系统上工作:)而我不是


编写代码的人...


提前致谢

Nitin

Ppl ,
Want to have ur opinions on having function calls like the one stated
below:
function funcA ( struct A *st_A , struct B *st_B )
{
st_A->a = st_B->a

}
Basically Is it a nice programming practice to have functions like this

especially when we can access both the structures in the calling
program ???
I want to know what will b the pros and cons of such calls ??
Will such calls effect the speed of execution by loading and unloading
the stack ????
Plz keep in mind that I m woking on a archaic system :) and I m not the

one who wrote the code ...

Thanks in advance
Nitin

推荐答案

Nitin写道:
Ppl,
想得到关于如下所述的函数调用的意见:

函数funcA(struct A * st_A,struct B * st_B)
{
st_A-> a = st_B-> a

}

基本上这是一个很好的编程习惯,有这样的功能

特别是当我们可以访问调用
程序中的两个结构时???
我想要知道这样的电话会有什么利弊吗?
这样的电话是否会通过装载和卸载来影响执行的速度????
Plz请记住,我是在一个古老的系统上工作:)我不是那个编写代码的人......

提前致谢
Nitin
Ppl ,
Want to have ur opinions on having function calls like the one stated
below:
function funcA ( struct A *st_A , struct B *st_B )
{
st_A->a = st_B->a

}
Basically Is it a nice programming practice to have functions like this

especially when we can access both the structures in the calling
program ???
I want to know what will b the pros and cons of such calls ??
Will such calls effect the speed of execution by loading and unloading
the stack ????
Plz keep in mind that I m woking on a archaic system :) and I m not the

one who wrote the code ...

Thanks in advance
Nitin




而不是直接进行分配,你付钱:

1:推动堆栈中参数的成本

2:成本函数调用指令

2:建立堆栈框架的成本

3:销毁堆栈框架的成本

4:返还指令的费用。


你获得了回报软件设计的可行性。

的详细信息分配和参数的结构是隐藏在函数调用后面的
。如果你有很多

这样的作业,你可以很容易地改变它们。

如果你直接写完作业,那就不是这样了

代码。


什么是更好的取决于情况,机器的速度,代码大小和代码速度的重要性等。


这里没有明确的决定。这是一个加权成本和优势的问题。



Instead of doing the assignment directly you pay:
1: The cost of pushing the arguments in the stack
2: the cost of a function call instruction
2: the cost of establishing a stack frame
3: The cost of destroying the stack frame
4: the cost of a return instruction.

You gain flexibility in software design. The details of
the assignment and the structure of the arguments are
hidden behind a function call. If you have many
assignments like this you can change them very easily.
Not so if you have written the assignment directly
all over the code.

What is better depends on the situation, the speed of the
machine, the importance of code size and code speed, etc.

There is no clear cut decision here. It is a matter of weighting
the costs and the advantages.


文章< 11 ********** ************@z14g2000cwz.googlegroups .com> ;,

Nitin< ni ****** @ gmail.com>写道:

:想得到你所说的功能调用的意见

:下面:


:function funcA (struct A * st_A,struct B * st_B)

:{st_A-> a = st_B-> a>}


:基本上是这是一个很好的编程习惯,有这样的功能


是的。

:特别是当我们可以访问调用中的两个结构时

:程序???


我不是你的意思吗?

:我想知道优点和缺点是什么这样的电话??

:这样的电话是否会通过加载和卸载来影响执行速度

:堆栈????


使用这么简单的代码,您的编译器可以内联

操作,直接执行效果替换调用。


如果a使用呼叫,开销取决于ABI和

架构。当传入少量值时,传递寄存器中的值将是常见的(但不是确定的)。调用

程序会看到寄存器本身没有被修改

因此不需要将寄存器保存在堆栈中。

返回地址可能必须在堆栈上,但这取决于架构和ABI的依赖

:一些ABI设置为保存

寄存器中的返回地址,如果被调用的例程判定代码很复杂,则由被调用的例程决定

保存该寄存器

足够保证。在某些体系结构中,生成的代码可能只需移动(A1),(A0);分支机构A7


这些需要对架构

和ABI的公平了解的事项超出了C规范,所以它们不是

通常在comp.lang.c中讨论过。

:请记住我在一个古老的系统上工作:)我不是

:编写代码的人...


假设您可以通过

直接执行任务来保存两个指令,但是所以需要重写

代码。重写代码需要多长时间?代码中会丢失多少

清晰度?现在,在程序的整个生命周期内,无需执行这两条指令即可节省多少计算时间




假设重写需要一个工作日(8小时)和[考虑你说

系统过时]假设机器每时钟运行500 MHz

周期,每个指令2个周期,每次调用保存4个周期

优化。


8小时* 60分钟/小时* 60秒/分钟* 500,000,000 cyles / s /

(4个周期/调用)= 3,600,000,000,000次调用


因此,您需要3.6万亿次调用才能实现收支平衡。

这可能吗?每次调用时刮掉8微秒

值得付出的努力吗?


当您处理优化时,请担心
的部分内容
您的代码 - 经证实 - 导致瓶颈。对于其余的代码,请以最可维护的方式编写它,

,因为其余代码的人工维护很可能

消耗的时间远远超过处理器使用的时间。

-

承认它 - 你偷看它以找出这条消息的方式结束了!
In article <11**********************@z14g2000cwz.googlegroups .com>,
Nitin <ni******@gmail.com> wrote:
:Want to have ur opinions on having function calls like the one stated
:below:

:function funcA ( struct A *st_A , struct B *st_B )
:{ st_A->a = st_B->a >}

:Basically Is it a nice programming practice to have functions like this

Yes.
:especially when we can access both the structures in the calling
:program ???

I''m not srue what you mean there?
:I want to know what will b the pros and cons of such calls ??
:Will such calls effect the speed of execution by loading and unloading
:the stack ????

With code this simple, your compiler may be able to inline the
operation, replacing the call with direct execution of the effects.

If a call is used, the overhead depends upon the ABI and upon the
architecture. When small numbers of values are passed in, it would be
common (but not certain) to pass the values in registers; the calling
program would see that the registers themselves are not being modified
and so would not need to save the registers upon the stack. The
return address may have to go on the stack, but that''s dependant
upon the architecture and ABI: some ABIs are set up to save the
return address in a register, and it is up to the called routine to
save that register if the called routine decides the code is complex
enough to warrant it. On some architectures, the generated code might
be as little as move (A1),(A0); branch A7

Matters such as these, which require a fair knowledge of the architecture
and of the ABI, are beyond the C specifications, so they are not
usually discussed in comp.lang.c .
:Plz keep in mind that I m woking on a archaic system :) and I m not the
:one who wrote the code ...

Suppose you were able to save two instructions per invocation by
doing the assignment directly, but doing so would require rewriting
the code. How long would it take to rewrite the code? How much
clarity would be lost in the code? Now, how much compute time would
be saved over the complete life of the program by not having to
execute those two instructions?

Say the rewrite took a working day (8 hours) and [considering you said
the system was archaic] suppose the machine runs at 500 MHz per clock
cycle, 2 cycles per instruction, so 4 cycles saved per invocation by
your optimization.

8 hours * 60 minutes/hour * 60 seconds/minute * 500,000,000 cyles/s /
(4 cycles/invocation) = 3,600,000,000,000 invocations

Thus you would need 3.6 trillion invocations just to break even.
Is that likely? Is shaving off an 8th of a microsecond per call
worth the effort?

When you are dealing with optimizations, worry about the parts of
your code that are -proven- to cause a bottleneck. For the rest
of your code, write it in the manner that will be most -maintainable-,
because the human maintenance for the rest of the code is likely to
consume far more time than would be used by the processor.
--
Admit it -- you peeked ahead to find out how this message ends!


Nitin写道:
Nitin wrote:
我想对你所说的函​​数调用有你的意见
下面:

函数funcA(struct A * st_A,struct B * st_B){
st_A-> a = st_B-> a
}


你把C与Fortran搞混了。

一个优秀的C程序员可能会写:


typedef struct AA;

typedef struct BB;


inline static

A * funcA(A * pA,const B * pB){

pA-> a = pB-> a;

返回pA;

}


来实现修改的函数一个东西 类型为A.

这是一个很好的编程习惯,有这样的功能
,特别是当我们可以访问调用程序中的两个结构时。
我想知道, 这些电话的优点和缺点是什么?
这些电话是否会通过装载和卸载电池来影响执行速度?


如果您宣布为*内联*,则不会。

请记住,我正在使用古老的系统进行维护:)
我不是编写代码的人。
I want to have your opinions
on having function calls like the one stated below:

function funcA(struct A *st_A , struct B *st_B) {
st_A->a = st_B->a
}
You have confused C with Fortran.
A good C programmer might write:

typedef struct A A;
typedef struct B B;

inline static
A* funcA(A* pA, const B* pB) {
pA->a = pB->a;
return pA;
}

to implement a function that modifies an object of type A.
It is a nice programming practice to have functions like this
especially when we can access both of the structures in the calling program.
I want to know, "What will be the pros and cons of such calls?"
Will such calls effect the speed of execution
by loading and unloading the stack?
Not if you declare then to be *inline*.
Please keep in mind that I''m woking on a archaic system :)
and I''m not the one who wrote the code.



这篇关于一行函数调用太多的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆