Re: Relocation patch for cygwin

[Charles Wilson]

On 9/23/2011 4:10 PM, jojelino wrote:
> It fixed the relocation problem. but led performance issue :(
> 
> $ time id > /dev/null
> 
> real    0m0.141s
> user    0m0.000s
> sys     0m0.000s

Well, the libiconv distributed as an official cygwin package *SHOULD*
not have been built with --enable-relocation, so only a subset of the
"relocation" code *OUGHT* to be involved -- just enough for any calls to
relocate() to return the passed-in string IIRC.

However...it appears that I MAY have mistakenly uploaded the version I
built WITH relocation enabled (which I generally do for testing
purposes, just to make sure it still works).  I'll need to double check.

> 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.

I'll double check both libiconv/iconv, and libintl/gettext -- but my
initial suspicions are that only libiconv/iconv was accidentally build
with relocation enabled.

> 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.

Right, and it is intended that, in the cygwin official packages, both
libiconv and libintl are built without relocation support.  If that
isn't true, it's a (cygwin packaging) bug.

I have no opinion on whether perceived slowness in the relocation code
itself, or in cygwin code called BY the relocation code such as
format_process_maps, constitutes a bug either in cygwin or gnulib.

--
Chuck