in reply to Slow startup on raspberry pi

Not enough information...

Try to benchmark which module is slowing down the startup and try to tell us why.

Cheers Rolf

PS: Je suis Charlie!

Replies are listed 'Best First'.
Re^2: Slow startup on raspberry pi
by vivat (Initiate) on Jan 16, 2015 at 12:23 UTC
    My script uses following modules: 
    use IO::Socket;
use Fcntl;
use strict;
use threads;
use threads::shared;
use MP3::Info;
use List::Util 'shuffle';
use LWP;
use Switch;
use Astro::Sunrise;

    [download]
    A simple script just printing "Hello World" needs with this modules more than 6 seconds to load whereby the last module (Astro::Sunrise) needs the longest time (ca. 2,5 s). The load time of the other modules is lower (< 1 second). With my more complex script I have almost the double load time until the first line is executed (with the same modules). Maybe perl is simply not appropriate on low performance platforms except for one-liners and I have to rewrite the stuff in C.
[reply]
[d/l]

      First thing you should look at on the Rpi is having a good power supply. Cheap old cellphone chargers won't cut it. I've had good success with the Canakit adapter. Since your program is I/O limited, finding a quality SD card is the second thing you should look at. Afraid I'm not as much help for this, but I usually buy Class 10 cards and get along OK.

      Looking at your list of modules, you should get rid of threads and threads::shared, preferably rewriting those pieces with fork(), or perhaps AnyEvent. A threaded perl build is noticeably slower than a non-threaded perl, and exists mainly to do pretend fork()s on Windows.

      (As an aside, I just noticed that the default Raspbian perl5.14.2 is compiled with threads. I'm not sure, but hiveberry may come with a perl without threads.)

      You can also ditch Switch and rewrite those parts as an if/elsif series, or perhaps given/when if you're feeling adventurous:

      http://perldoc.perl.org/perlsyn.html#Switch-Statements

      Just doing those, I think you'll be able to chew off a few seconds at startup time.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]
[d/l]
[select]
      Maybe perl is simply not appropriate on low performance platforms except for one-liners and I have to rewrite the stuff in C.

      But I thought earlier you said "Once running, the performance is good"? It sounds like you're just running this script once on boot, like a daemon, or does it get started & stopped more often? If just once on boot, I'm not sure what the problem is, why do you really need to optimize the boot time? I understand the speed might be a bit annoying during development but hey, that's the price for running on that hardware ;-) Maybe you can develop on a desktop machine?

      The Rasperry Pi is in general "slow" by modern standards so if you want to use it you'll have to live with a bit of relative slowness no matter what you do with it - try running startx on it to get a feeling for the speed! FWIW, I've written a bit of Perl for the Pi myself, admittedly with less modules than you're using, and those scripts ran just fine.

[reply]
[d/l]
        The overall boot time is crucial for that application. I optimised the raspberry pi boot time to 20s but get additional more than 10s by this perl script. I.e. the whole linux system needs 20s but a simple perl script adds 10s.
[reply]

      I

      there is special consideration on 'use threads;' - start these as early as possible, and yet http://perlmonks.org/?node_id=288022: they are not lightweight, (although some people argue and have different opinion)

      All in all, is this 'use threads;' really a necessity in your script?

      Starting several scripts in parallel could better do the job, IMO.

      II

      I do have a real advise on how to divide startup time of your use ...; lines by factor of 4,

      Those 'use'-d modules are loaded on the fly by 'use' statement and their blabla.so.x object loaded.
      Just build these modules statically, and you're done!

      I have tried this approach on windows only (on linux I only used standard perl and my own ordinary builds at /opt/...)
      On windows, I successfully statically linked perl modules statically into perl executable, fortunately the Win32 makefile allows to do so.

      If startup time is still slow after that, then rip out the Autoloader, so this will avoid usage of a large amount of tiny files, instead most will be loaded quickly.
      Also there is another boost option, I'll let you know on that if needed, ...

      PS. in earlier days, when perl run just fine on 486, it was small and quick, and the problem of slow startup was not on the table.
      :)

[reply]
[d/l]
[select]
        Earlier start of threads did not help. I'm thinking about to rewrite the script without threads, but I'm afraid it wont help much. To speed up the start by factor 4 would really solve the problem. But to make the whole perl from source for static linking is probably on a raspberry pi a never ending story. I'll give a try. Thank you for the hint.
[reply]
[reply]
        It's not about blaming perl but rather some "horses for courses" thing...
[reply]

      Due to the requirements of the modules that you are loading, you are actually reading in a lot more than you think. The actual list is more along the lines of -snip- something too large to actually post here.

      Try using scandeps from Module::ScanDeps against your code (even just the list of use statements) and take a look at everything that Astro::Sunrise is requiring from the DateTime tree.

[reply]

In Section Seekers of Perl Wisdom