Re^2: Wisdom for building an Efficient Perl/PerlMagick?

AM,

>> Your perl build options should be of little consequence

As glue for IM, the Perl should make little difference. But to change
the guts of Perl itself by making libperl.so instead of libperl.a,
everything else I do with Perl will pay the ~20% penalty for being a
shared object.

Is there any way that I can use the shared Perl just for PerlMagick,
use the standard, static Perl for everything else and keep just 1 set
CPAN modules (~50 bleepin modules I had to rebuild with new machine)

Or, would I have to do parallel maintenance?

Third option? Force a static link on PerlMagick and live with a 20MB
Perl_The_Hutt?

BORING STATIC VS SHARED TRIVIA SECTION:
==========================================
I have both libperl.a and libperl.so built the same except for sharedness
Ldd confirms that their guts are identical except for 1 file:

ldd `find /usr/local/bin -name perl` | psr "s/\(.*//" | freq -s
libperl.so => /usr/local/bin/im/lib/perl5/5.22.1/x86_64-linux/CORE/lib
+perl.so
/usr/local/bin/im/perl:
/usr/local/bin/perl:
[download]

The total size too is interesting, .a is 2 MB fatter:

lsr -s `bloc -s  libperl. | grep 5.22`
/usr/local/bin/im/lib/perl5/5.22.1/x86_64-linux/CORE/libperl.so  20018
+56
/usr/local/lib/perl5/5.22.1/x86_64-linux/CORE/libperl.a          30494
+58
[download]

The size of the .so version of Perl too looks tiny, on the surface:

lsr -s `find /usr/local/bin -name perl`
/usr/local/bin/im/perl    17400
/usr/local/bin/perl     1887720

add 17400 2001856  ->  2019256;  add 2019256 -1887720  ->  131536
[download]

The stump and the shared object together, however, are
131 THOUSAND BYTES larger than boring old STATIC PERL!

So, the shameless canard about shared libs saving disk space
and memory has finally been INESCAPABLY DEBUNKED!
They take up more memory, more disk space and they extort a
surcharge against your TIME with every Invocation!

Comment on Re^2: Wisdom for building an Efficient Perl/PerlMagick? Select or Download Code

Replies are listed 'Best First'.
Re^3: Wisdom for building an Efficient Perl/PerlMagick? by Anonymous Monk on Mar 17, 2016 at 19:10 UTC
I believe selecting a particular compiler has more of an effect on perl performance than the issue of shared/static build. Gcc-4.8 seems to produce better executable than either gcc-5.3 or clang (possibly due to match of development toolset). Having done no extensive benchmarking, I cannot offer anything conclusive, however. I would advise you to trust the wisdom of perl maintainers (and their configure tools) and the wisdom of perl vendors (OS providers). E.g. the latest slackware-stable ships with shared perl (-Duseshrplib). If you believe that a different set of compile options would prove generally superior by a large margin, then this is a claim you need to substantiate. Test it, show it, prove it.	[reply]
Re^4: Wisdom for building an Efficient Perl/PerlMagick? by BrianP (Acolyte) on Mar 18, 2016 at 23:08 UTC
For a job that kicks off once every hour, the startup cost of shared loading would be negligible. For Image Processing, times are more likely to be seconds or milli-seconds. This is what I do when processing 400 pictures from a shoot. Mod_Perl has an apparent speed close to C because it does everything possible up front; finding Perl, reading the disk image, initializing it and pre-compiling the code. No dawdling with LD_LIBRARY_PATH, ld.so, finding the latest library module, hoping nobody changed the compiler options, gluing this to that, doing auto-variable initializations, and on and on... before running. Just to do a very rough sanity test, I ran a quick script which examines an uncompressed TIF, determines the XY res and Bytes/Pixel, then calculates where the header stops and the raw image data begins and returns either the header or the RAW. Interestingly, the programs themselves measured 7.12% difference (libperl.a faster that libperl.so), however the calling script which launched each with a simple system() call and measured the response time saw 12.62% difference. Same Perl code base, same Perl script, same image. Annoyingly, I had to copy-n-paste 4 small functions from my KitchenSink.PM module into the test script so I would not have to rebuild dozens of perl modules for /usr/local/bin/->_IM_<-/perl. Paying a 12% performance penalty from now til Doomsday to have the pleasure of using PerlMagick is an obnoxious and onerous prospect. Building 50 Perl modules now and doing double maintenance for any module I wish to use with PerlPerl and PerlMagick is a much higher cost today but vastly less time cost to me in the long run. As Kirk told Spock and Bones in "Operation -- Annihilate!" (the one with with the fried egg neuro-monsters that killed Jim's brother), I want a third option! How hard would it be to have static linking for IM core, libperl.a and libJPEG.a, the 3 modules used almost every time, and others shared? There are rumors of gcc being able to link both static and shared on the same command line. What kind of worms will spring out of that can??	[reply]