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


in reply to Building a small perl

I'm curious, did any of that help? I can't imagine it shaved more than a few hundred k. And a lot of that "saving" would be in shared libs that are probably already in memory.

You're not giving us a lot of details to work with here, but here's a few random suggestions. First, turn off caching - lots of modules support caching data and you don't want them to do that if memory is scarce. Second, switch to straight CGI if you're using mod_perl - mod_perl is fast because it keeps your app in memory, but you don't want that. CGI will immediately release all memory used by a script as soon as it returns results. Finally, look critically at which modules are being used and make sure you really need them. Having a Project::All module with use statements for all your CPAN modules is very convenient but it will kill your memory usage if you're running a script that only needs a few deps.

If you want more useful advice you'll have to give us more information - what does the app do, what CPAN modules does it use, does it leak memory, etc.

-sam

Replies are listed 'Best First'.
Re^2: Building a small perl
by awy (Acolyte) on Mar 21, 2009 at 19:47 UTC
    I already have some reasonably good data about the size of the complied perl code (not the native executable) and how much of it is ours and how much comes from CPAN, etc.; using Devel::Size & Devel::Size::Report. With this analysis it is clear that most of this is our own code. And I really am talking about the size of the compiled code, not data.

    Actually, changing the build options did make a big difference. I think excluding threading was the big win. Altogether those options, coupled with a switch to 5.10 from 5.8, saved about 30%. But even as it stands, the in-memory image include a lot of overhead just for the filenames and module names: about one instance of each of those strings for each executable line of code in the source files.

      I think excluding threading was the big win

      Yes, you want to stick with that one.

      a switch to 5.10 from 5.8, saved about 30%

      I think a switch back to 5.6 will also provide a further significant reduction (untested). You could even go further back, if you like - though the further back you go the more likely it becomes that you'll have to make amendments to the code you want to run.

      Cheers,
      Rob