From: Vincent T. <vt...@un...> - 2011-10-28 14:45:56
|
On Fri, 28 Oct 2011, Cedric BAIL wrote: > On Fri, Oct 28, 2011 at 2:13 PM, Youness Alaoui > <kak...@ka...> wrote: >> I agree with vincent, and I think that there shouldn't be a "define it >> before including eina.h" implicit rule.. while it's not so bad, and it would >> work, it's not the right way to do it. >> these functions shouldn't be inlined I think, they should be a define, and > > Using define instead of inline has a lot issue. First it doesn't let > the compiler when it's better or not to inline, it will always inline. > Second it doesn't do any type checking so you can break stuff much > more easily. And generally inline is much more easy to read than > define. > >> for the posix functions, they are way too big to be inline, they would >> dramatically increase the generated code, especially if you lock/unlock >> everywhere. > > I actually don't understand what point your are trying to make here. > >> As for performance, give us hard numbers! I don't think it would >> affect performance for such function calls. So in my opinion, make them >> defines, and have the posix versions as actual functions that the defines >> call (so for non posix with smaller functions, you don't need an actual >> call). > > What does matter is call to small function, because the overhead of > setting up the stack, saving register, jumping to the actual function > to call and then coming by restoring register and the stack does > introduce a cost. Something you will not see on your high end laptop, > but on embedded device. And the inline function are function that are > typically in the hot path of our stack, so function call really do > matter. And moving to #define would not solve the issue Vincent is > pointing as far as I understand it. indeed. So, with the argument of Jorge, there are 2 problems. Vincent |