change log for rtems (2010-06-22)

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Jun 23 12:23:05 UTC 2010


On 06/23/2010 02:16 PM, Joel Sherrill wrote:
> On 06/22/2010 08:49 PM, Chris Johns wrote:
>> On 23/06/10 6:12 AM, rtems-vc at rtems.org wrote:
>>   
>>> diff -u rtems/cpukit/libcsupport/include/rtems/libio_.h:1.37
>>> rtems/cpukit/libcsupport/include/rtems/libio_.h:1.38
>>> --- rtems/cpukit/libcsupport/include/rtems/libio_.h:1.37    Mon Jun
>>> 14 08:35:45 2010
>>> +++ rtems/cpukit/libcsupport/include/rtems/libio_.h    Tue Jun 22
>>> 15:03:41 2010
>>> @@ -148,13 +148,7 @@
>>>     *  Macro to free a node.
>>>     */
>>>
>>> -#define rtems_filesystem_freenode( _node ) \
>>> -  do { \
>>> -    if ( (_node)->ops )\
>>> -      if ( (_node)->ops->freenod_h ) \
>>> -        (*(_node)->ops->freenod_h)( (_node) ); \
>>> -  } while (0)
>>> -
>>> +void rtems_filesystem_freenode( rtems_filesystem_location_info_t* 
>>> node );
>>>
>>>      
>> Why has this been done ?
>>
>> This code is a hot spot in the file system. Not all file systems need to
>> free a node but they now suffer an extra call. Maybe the overhead is not
>> too much but it does add up.
>>
>>    
> It lead to horrible branch patch explosion and code size.   It introduced
> a lot of paths that had to tested.  Look at the top two entries here:
> 
> http://www.rtems.org/ftp/pub/rtems/people/joel/coverage/erc32.html#OsPD
> 
> Code coverage went up about 4%!!! And the number of branches which
> are executed but we have only taken one direction (e.g. always taken
> or never taken) dropped from 727 to 626.

We should consider to forbid NULL pointers for ops tables and handlers.
Instead we should provide reasonable default handlers.  This would eliminate a
lot of ifs and make the code more readable.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the vc mailing list