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
