Re^3: Slow startup on raspberry pi

[vkon]

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.
:)

[vivat]

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.

[soonix]

But to make the whole perl from source for static linking is probably on a raspberry pi a never ending story.

Haven't done it myself, but in this situation I'd try cross compiling. Google comes up with http://arsv.github.io/perl-cross/

[vkon]

I'll expand a little on my Win32 experience on what I did when I did static ilnkage of perl modules into main executable, which could help you some.
• rebuilt perl some needed XS modules statically, (this step could be skipped, actually)
• installed said perl into some dir for my edits (this could be just normal /opt/perlXXX setup for example)
• I cut out all of the Autoloader infrastructure
• use something like Module::Scandeps to get needed "pm" files *and* packed these into ZIP; or you can even ZIP all of perl module PMs
• some ~20 xxx.pm files are required to bootstrap Archive::ZIP to look into said ZIP archive, so I made in-memory hash of these files, yet I made it fast-to-load by some special technicque, yet I used Compress::Zlib to in-memory_compress it and placed into __DATA__ segment of my bootstrapper
• I hooked "CORE::require" so that they look into either said ZIP or into in-memory-hash
As a result, I had these 4 files:
• perl.exe + my larger perl58st.dll (with statically linked extensions, but normal perl.so will also suffice here)
• perllib.zip - to contain all pm files
• compr.pm - my mentioned hooker and bootstrapper
These 4 files contained entire setup with any said number of modules inside, except you should place module's shared library into the same dir, so it will be about 10 files more...

Given that static build isn't easy for you, all other steps could still apply and give you a speed win...

addition just thought, that my way gives you universal perl that is quicker-to-startup... If you need faster application run, you can avoid ZIP usage, and place all into in-memory-compressed content, so will be much simplier (yet smaller and faster), but less universal.

HTH,
vkon

[LanX]

Pourrait être que ça t'intéresse:

Perlcc talk YAPC NA 2014

Mais cette présentation est malheureusement que en anglais! 😢