http://qs321.pair.com?node_id=11143151


in reply to Trading compile time for faster runtime?

Others have already noted profiling as the way forward. Devel::NYTProf is the go-to for that.

The best optimisation is to use an algorithm that avoids doing much of the work in the first place, but sometimes you just need faster implementations.

If you are on a recent-ish perl then the refaliasing feature can be used to avoid repeated dereferencing of array items inside loops (see also Data::Alias). It is only really worthwhile when there are very large numbers of derefs that can be avoided. It is also still experimental if that is a concern.

Data::Recursive has some fast methods to merge data structures (the difference is a few percent so it is more useful for larger data sets or frequent mergers). It depends on some complex modules so installation does not always go smoothly, and hence it is not safe to assume it is available on end-user machines. This means fallback code is needed, which leads to extra maintenance load.

I have not tested these next few but they might be useful. Devel::GoFaster speeds up some common ops and is in the spirit of your question. There are also a few modules from PEVANS, the contents of which might make their way into future perl releases: Faster::Maths speeds up some mathematical processing, List::Keywords provides faster versions of some List::Util subs (but currently fails tests on Windows).

Version 5.36 will also have the option to disable taint checking. This will apparently speed up a lot of processing. I haven't seen any benchmarking yet but the current development release includes it as an option: https://metacpan.org/release/SHAY/perl-5.35.11/view/pod/perldelta.pod#Configuration-and-Compilation.

  • Comment on Re: Trading compile time for faster runtime?

Replies are listed 'Best First'.
Re^2: Trading compile time for faster runtime?
by melez (Sexton) on Apr 21, 2022 at 09:44 UTC

    I actively use NYTProf, it is a great tool. But others you mentioned are new to me, and seem really useful! Will try them out later, but this is pretty much what I asked for.

    But actually, you can disable taint checking for some time now, however it is not a configure option, which 5.36 will fix. I heard it gives like +5% speed, and together with no threads support (~ +15%?) it gives even more incentive to build your own perl.

[reply]

      The speedup you might get for not supporting threads very much depends on your compiler, your OS, your OS thread support (Linux, Windos, VMS, z/OS, HP-UX, AIX, …) and the configuration of your perl. There is no single number that can be pinned to how much slower/faster perl will be (runtime) when built with/without a configuration option.

      For the systems I run a smoke-test on, the gain for non-threaded perl is about

      See https://tux.nl/perl5/smoke/index.html for smoke results, and a summary at the page bottom regarding performance differences:

      threaded   is   6.1% slower than non-threaded
DEBUGGING  is   2.5% slower than non-DEBUGGING
gcc/g++    is  29.7% slower than cc              (cc vs. gcc on non-Li
+nux and gcc vs. g++ on Linux combined)
stdio      is   8.5% slower than perlio

      [download]

      Enjoy, Have FUN! H.Merijn
[reply]
[d/l]

        It is worth keeping in mind that perl's test suite is not designed for benchmarking, and probably spends the majority of its time doing things very unrepresentative of any kind of normal workload. So while these timings may give a rough indication which build options are likely to be faster, any specific real workload will have its own unique set of timings which are unlikely to map closely to these figures.

        For one $work application a few years ago, we came up with a figure of about 25% speedup for a perl built without threads, for example. (That was probably around perl-5.18.) There's really no substitute for testing things on your own workload (which I think @Tux was saying, but not sure the message got through :).

[reply]

        Are those times for the full build process or just running the tests?

        And do I read the table correctly in that the second of the repeated row labels is for g++ on linux and gcc on non-linux?

        A short extract is below showing two rows for the first two columns, representing "HP-UX - 11.11" and "HP-UX - 11.23". These are non-linux so am I correct that this means 106.3 for cc and 147.4 for gcc on those platforms? Although then I'm wondering what the values after the forward slash are.

        -Duse64bitall     106.3 /  97.2      59.6 /  66.3     
-Duse64bitall     147.4 /            79.7 / 108.4

        [download]

        Edit: But now I see the labels at the bottom of the table, so the repeated labels are for where -DDEBUGGING is set, and the forward slash separates the compilers. That answers the second part of my question.

[reply]
[d/l]

In Section Meditations