Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

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

by Anonymous Monk
on Mar 17, 2016 at 19:10 UTC ( [id://1158146]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Wisdom for building an Efficient Perl/PerlMagick?
in thread Wisdom for building an Efficient Perl/PerlMagick?

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.

Replies are listed 'Best First'.
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??

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1158146]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2024-03-29 02:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found