change log for rtems (2010-06-22)
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Jun 23 15:07:01 UTC 2010
On 06/23/2010 09:57 AM, Joel Sherrill wrote:
> On 06/23/2010 07:23 AM, Sebastian Huber wrote:
>
>> 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.
>>
>>
>>
> I was thinking of the same thing. There are a LOT of places there
> are checks and having standard stubs would really help the code.
>
> As we try to improve testability, this type of thing is a very good
> technique. Plus it also improves readability IMO.
>
>
I hate to reply to myself but this would eliminate a lot of
branches that have to be tested and the need for the corresponding
test code. FWIW libcsupport has 46 tests for NULL op handlers
$ grep "\!.*op" *.c | wc -l
46
Now look at the summary for the coverage run last night
Bytes Analyzed : 120464
Bytes Not Executed : 9860
Percentage Executed : 91.81
Percentage Not Executed : 8.185
Uncovered ranges found : 322
Total branches found : 2742
Uncovered branches found : 626
243 branches always taken
383 branches never taken
Let's assume that only 40 of the ones shown by grep are
eliminated. That is at least 40 fewer branches. :)
--joel
More information about the vc
mailing list