[PATCH] _dl_find_hash: optmizie symbol lookup delaying stringcomparisons
Carmelo AMOROSO
carmelo.amoroso at st.com
Fri Oct 5 08:04:15 UTC 2007
Carmelo AMOROSO wrote:
> Joakim Tjernlund wrote:
>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Carmelo AMOROSO [mailto:carmelo.amoroso at st.com]
>>> Sent: den 4 oktober 2007 20:00
>>> To: Joakim Tjernlund
>>> Cc: uclibc
>>> Subject: Re: [PATCH] _dl_find_hash: optmizie symbol lookup
>>> delaying stringcomparisons
>>>
>>> Joakim Tjernlund wrote:
>>>
>>>
>>>> Hi Carmelo
>>>>
>>>> This has been up before and I am not convinced it is a gain.
>>>> The if (sym->st_value == 0) and if
>>>>
>>>>
>>> (ELF_ST_TYPE(sym->st_info) > STT_FUNC)
>>>
>>>
>>>> are mostly false.
>>>>
>>>> Suggest you get some numbers before applying this patch.
>>>>
>>>> Jocke
>>>>
>>>>
>>>>
>>> Joakim Tjernlund wrote:
>>>
>>>
>>>> Hi Carmelo
>>>>
>>>> This has been up before and I am not convinced it is a gain.
>>>> The if (sym->st_value == 0) and if
>>>>
>>>>
>>> (ELF_ST_TYPE(sym->st_info) > STT_FUNC)
>>>
>>>
>>>> are mostly false.
>>>>
>>>> Suggest you get some numbers before applying this patch.
>>>>
>>>> Jocke
>>>>
>>>>
>>>>
>>> Hi Jocke, here they are the numbers you were asking for ;-)
>>>
>>> I've run the uClibc testsuite (using sh4 nptl as usual for me :-) )
>>> to collect data.
>>>
>>> I've executed them (316 tests) in 4 different scenarios:
>>>
>>> 1) SysV hash - *no* strcmp patch
>>> 2) SysV hash - *with* strcmp patch
>>> 3) GNU hash - *no* strcmp patch
>>> 4) GNU hash - *with* strcmp patch
>>>
>>> To get figures, I have hacked the ld.so adding a variable
>>> to count how many times the ld.so calls a strcmp to check
>>> for a symbol matching and it fails, printing it to stderr
>>> before the linker passes the control to the application.
>>>
>>>
>> I hope you linked/run with LD_BIND_NOW enabled, else you miss all JMP_SLOT calls
>>
>>
> No, only the linker itself is built with -z now so it has BIND_NOW into
> the dynamic section, all other libs
> not, and I don't set the LD_BIND_NOW variable at runtime; all JUMP_SLOTs
> are lazily relocated.
> I'm counting only the relocation done at startup time.
> I don't understand your doubts... I'm missing something?
>
Ok, I've caught what you was saying... yes, I miss all strcmp calls
during the lasy JMP_SLOT relocation.
I can do same tests forcing BIND_NOW to count all.... any way the
results I expect should confirm the goodness of the patch :-)
Carmelo
More information about the uClibc
mailing list