lkml.org 
[lkml]   [2015]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: First kernel patch (optimization)
From
Date
On 2015-09-15 20:09, Steve Calfee wrote:
> On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin <ericcurtin17@gmail.com> wrote:
>> Signed-off-by: Eric Curtin <ericcurtin17@gmail.com>
>>
>> diff --git a/tools/usb/usbip/src/usbip_detach.c b/tools/usb/usbip/src/usbip_detach.c
>> index 05c6d15..9db9d21 100644
>> --- a/tools/usb/usbip/src/usbip_detach.c
>> +++ b/tools/usb/usbip/src/usbip_detach.c
>> @@ -47,7 +47,9 @@ static int detach_port(char *port)
>> uint8_t portnum;
>> char path[PATH_MAX+1];
>>
>> - for (unsigned int i = 0; i < strlen(port); i++)
>> + unsigned int port_len = strlen(port);
>> +
>> + for (unsigned int i = 0; i < port_len; i++)
>> if (!isdigit(port[i])) {
>> err("invalid port %s", port);
>> return -1;
>>
>> --
>
> Hi Eric,
>
> This is fine, but what kind of wimpy compiler optimizer will not move
> the constant initializer out of the loop? I bet if you compare binary
> sizes/code it will be exactly the same, and you added some characters
> of code. Reorganizing code for readability is fine, but for compiler
> (in)efficiency seems like a bad idea.
While I agree with your argument, I would like to point out that it is a
well established fact that GCC's optimizers are kind of brain-dead at
times and need their hands held.

I'd be willing to bet that the code will be marginally larger (because
of adding another variable), but might run slightly faster too (because
in my experience, GCC doesn't always catch things like this), and should
compile a little faster (because the optimizers don't have to do as much
work).

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2015-09-16 14:01    [W:0.130 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site