[FFmpeg-devel] Visibility implementation

[Måns Rullgård]

Uoti Urpala wrote:
> On Wed, 2008-07-30 at 16:54 +0100, M?ns Rullg?rd wrote:
>> M?ns Rullg?rd wrote:
>> > Uoti Urpala wrote:
>> >> On Wed, 2008-07-30 at 15:40 +0100, M?ns Rullg?rd wrote:
>> >>> Uoti Urpala wrote:
>> >>> > On Wed, 2008-07-30 at 08:16 +0200, matthieu castet wrote:
>> >>> >> Did you see any code change with your attribute patch ?
>> >>> >
>> >>> > Yes, if compiling with -fPIC.
>> >>>
>> >>> On which architecture?  How did it compare to vanilla code without
>> -fPIC?
>> >>
>> >> I think it should change the resulting code on any architecture, but
>> >> exactly how differs.
>> >
>> > Any benchmarks?
>
> No.

Come back again when you have some.

>> >                  If it is faster than the fastest alternative on each
>>                            ^not
>> > architecture, I see no point in pursuing this.
>
> It makes the code faster when compiling with -fPIC, the question is only
> whether or in which cases the speedup is significant. I'm not sure what
> "alternatives" you're talking about.

Using static libraries, building without -fPIC (where possible), building
with -fPIC.

> Code improvements are not the only benefit. Currently libavcodec.so
> exports 1100 symbols for use by external programs, most of which it
> shouldn't. The patch I posted cuts this to about one third, and
> completing the visibility markup would make it fall further. That
> difference exists whether the library is compiled with -fPIC or not.

1. Does it matter?
2. Static libs still export all the stuff, so any namespace arguments
   are irrelevant.
3. Selectively exporting symbols can be done more easily, and on more
   platforms, with linker tricks.

>> > I know there are people
>> > who find some kind of twisted pleasure in obfuscating perfectly good
>> > code with non-standard hacks and directives, but I'm not one of them.
>
> Visibility is fairly standard library functionality nowadays.

If by standard, you mean gcc, yes.

-- 
M?ns Rullg?rd
mans at mansr.com