On 10.09.2018 16:47, Jean Delvare wrote: > On Mon, 10 Sep 2018 15:43:21 +0200, Martin Schwidefsky wrote: >> On Mon, 10 Sep 2018 15:05:05 +0200 >> Jean Delvare <jdelvare@xxxxxxx> wrote: >>> I can't see how it could or would even want to. I know that the >>> compiler can reorder independent instructions for optimization >>> purposes, but as far as I know it is not allowed to execute functions >>> in anticipation "just in case" - the compiler has no idea what side >>> effects calling a function can have. Plus, all the benefits of the >>> optimization would potentially be lost or even negated by the cost of >>> the function call. ... > > Says +4 here. Might depend on the compiler (gcc 4.8.5 here). One more > function call but one less local variable. > >> That function is rarely used, no? Then I am not sure if we are >> making the right trade-off. I leave the decision to our network >> maintainers.. > > I'm not familiar with the driver so I can't answer that question. I am > sure it rarely does something (otherwise I guess that the kernel log > would be filled with qeth messages? I'm not sure how qeth_dbf works to > be honest.) What I can't evaluate is how frequently it is called only > to return immediately. And this is the case where my patch makes a > difference. > > My reason for avoiding unnecessary calls to qeth_get_ipa_cmd_name() is > because my previous patch makes it slower than it was before. I wanted > to limit the performance impact of the change. Now if the maintainers > do not care how fast qeth_issue_ipa_msg() is and prefer to keep the code > as it is, that's fine with me, I don't even use the driver ;-) > > Thanks for the review and comments, > Thanks Jean, but I'd rather pass on this one. I don't see an improvement in readability, and performance just isn't a concern for this specific path... there's hardly any traffic on the interface's control plane.
