On Mon, 1 Jun 2020, Tim Mooney wrote:
In regard to: [OpenIndiana-discuss] ICU update and rebuilds, Aur?lien...:
ICU is being updated to a non-ABI compatible version and quite a few
components need a rebuild...so the server will be quite busy and
unavailable at times in the coming 10 hours.
I would suggest postponing any update...
I looked at updating ICU about 6 months ago, saw the list of dependencies,
and decided to tackle other packaging updates that didn't seem so
insurmountable.
GraphicsMagick has had this to say about ICU in its release notes for
some time:
* It has been discovered that the 'ICU' library (a perhaps 30MB C++
library) which is now often a libxml2 dependendency causes huge
process initialization overhead. This is noticed as unexpected
slowness when GraphicsMagick utilities are used to process small to
medium sized files. The time to initialize the 'ICU' library is
often longer than the time that GraphicsMagick would otherwise
require to read the input file, process the image, and write the
output file. If the 'ICU' dependency can not be avoided, then make
sure to use the modules build so there is only impact for file
formats which require libxml2. Please lobby the 'ICU' library
developers to change their implementation to avoid long start-up
times due to merely linking with the library.
Besides the build issues, I suggest taking care about how ICU is
deployed and linked in the system. It appears that ICU expects that
applications using it are long-lived, have a lot of resources, and can
afford to take a long time to start up. An incidental linkage of ICU
to satisfy a few apps requirements may have the unintended consequence
of making many other apps slow and memory-hungry. I don't think that
we want OpenIndiana to feel sluggish and slow.
It is my guess that the ICU shared libraries use C++ static
constructors (or a shared library equivalent) to perform
expensive/protracted initialization when the shared library is loaded,
regardless of if its functionality will ever actually be used! Just
linking with the library (without invoking any API which might use it)
afflicts the dependent application.
An optional libxml2 dependency often brings in this steaming pile and
thus afflicts the many applications which link with libxml2.
My mind was boggled when I saw apparently trivial commands taking a
substantial portion of a second under Linux. I expect that the
situation would be worse with Illumos.
Bob
--
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
_______________________________________________
openindiana-discuss mailing list
[email protected]
https://openindiana.org/mailman/listinfo/openindiana-discuss
