Re: Wisdom for building an Efficient Perl/PerlMagick?

PerlMagick is a glue module for interfacing with ImageMagick. Heavy lifting is done by the latter. Your perl build options should be of little consequence. Check that the ImageMagick library itself is built with optimizations.

Generally speaking, for best results you'll want link-time optimization and the latest, greatest compilers. (And -march -Ofast, if suitable.) This is especially true for routines that can be autovectorized. For perl, I doubt it matters much. FWIW, the following appears to work:

cd perl-5.22.1 &&
./Configure -des -Duseshrplib -Dusethreads -Duseithreads -Dcc='clang-3.8 -flto' &&
make install

Finally, if you feel like exploring alternative options, [http www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use|here are] some image processing benchmarks. Though I've no idea which libraries (besides ImageMagick) have perl glue...

Comment on Re: Wisdom for building an Efficient Perl/PerlMagick?

Replies are listed 'Best First'.
Re^2: Wisdom for building an Efficient Perl/PerlMagick? by BrianP (Acolyte) on Mar 17, 2016 at 03:07 UTC
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!	[reply] [d/l] [select]
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]