Mail Archives: cygwin/2011/09/23/20:56:02
On 23/09/2011 4:10 PM, jojelino wrote:
> On 2011-01-29 AM 3:04, Charles Wilson wrote:
>> On the cygwin list, Corinna Vinschen, one of the main cygwin developers
>> and project lead, noticed a problem with libiconv's behavior on cygwin
>> 1.7.x (which I'll follow up on the appropriate list, in a few days).
>>
>> However, while she was investigating it, she ran across some very
>> obsolete code in the relocation support employed by libintl. In keeping
>> with cygwin's mantra of "more like unix, less like windows", she
>> suggested the following changes. These basically make cygwin's
>> relocation support use the linux machanisms (/proc/self/maps,
>> /proc/self/exe) rather than relying on win32 mechanisms like
>> GetModuleFileName, DllMain(), and the like.
> It fixed the relocation problem. but led performance issue :(
>
> $ time id > /dev/null
>
> real 0m0.141s
> user 0m0.000s
> sys 0m0.000s
>
> The attached is report gprof produced when invoked *id* . as you can
> see, format_process_maps consumes 70% of the lifetime(0.5s with
> profiling overhead). this is reproducible whenever we do
> open('/proc/self/maps').
> the problem is, the cost is too expensive. gnulib should care about
> cygwin do sacrifice performance for compatibility.
> As a workaround, how about rebuild libintl without capacity of
> relocatable?
> because in cygwin libintl is expected to place in /bin so there's no
> use of relocatable.
Hmm. I'm not up to speed on what the relocation issue is/was, but from
what I've seen of the proc/*/maps code path, they are expensive enough I
would think twice about putting it on the critical path. That said, the
amount of time consumed makes me wonder if the file is being opened/read
multiple times, resulting in O(n^2) work overall.
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -