On Sun, Dec 12, 2010 at 8:48 PM, Thilo Planz <thiloplanz@...> wrote:
>> I'm to a point in 2.0 development where I have a working framework
>> that's completely standalone. That is, it includes its own libperl,
>> and CBPerl's -eval: method works with it.
>> The problem is, it's bloody huge... 81.9MB.
>> So, I'm thinking about what *needs* to be included in the framework
>> for use at run time, and what can be left out.
>
>> That leaves the framework at 52.3MB. To me, that still seems pretty
>> big, but looking around in /Applications it seems to not be
>> *completely* out of line.
>> A .zip archive of the framework is
>> only 14.9MB, which IMHO is quite reasonable for a download, even for
>> someone on dialup.
>>
>> Comments? Thoughts? Rants? Complaints?
>
> I am very happy to hear that you got this working.
>
> I agree with your assessment about the things you removed being
> not needed for embedded use in a normal CB application.
> (I assume that you can specify in your build script that you want to
> copy extra stuff, I you need it).
Certainly. The developer package will include a complete install of
Perl under /Developer/CamelBones/Perl/. That's what developers could
use, for instance, to build CPAN modules to bundle into apps. And, as
you say, it could be used as a source to copy anything that isn't
included in the framework by default.
> For future releases, do you think it would make sense
> to give an option to explicitly specify a subset of core Perl modules
> to include in (or exclude from) your application build? (You may not
> need CGI.pm, for example).
> By "making sense" I mostly mean, would the reduction
> in download size be worth the considerable effort to
> figure out the dependencies?
I was wondering about that too, and I think the dependencies could be
found in a semi-automated way. %INC has a list of all the files that
have been loaded with use(), require(), or do(). The keys are the file
names as specified in the command, and the values the path at which
they were found. If the full install of 5.12 were appended to @INC,
after the Resources/ dir in the framework, then an END block could
then report any values in %INC that begin with /Developer/CamelBones.
I refer to that as semi-automated though, because the values in %INC
are just the paths to the .pm files, and some modules (XS modules with
.dylib components in particular) would need additional files.
> How big is the bundle when you delete all Perl modules?
> (That would not leave the embedded Perl functional
Right now, 3.6 MB. That *should* leave some bare-bones minimal
functionality though, because libperl is statically-linked. It would
be able to execute standalone Perl source that didn't use any modules,
and that's about it. Without CamelBones.pm, which is where virtually
all of the bridge code resides in 2.0, Perl code can't call ObjC
methods, Perl classes aren't registered with the runtime, etc.
Note that the current (1.1.2) framework is 10.3 MB. Obviously, apps
that run user-supplied code (such as your own PerlPad, and Rachel's
Atlantis) can't predict what core modules will be required at run
time, and will thus need to include them all. Other apps (Matt's DVD
Spanner for example) only run the code that's included in their own
.app bundle. With careful pruning of the Perl install down to exactly
what's necessary to run the app, and no more, the second sort of app
could actually be *smaller* with 2.0 than it is with 1.1.2.
> Finally, the size of the embedded framework only has an impact
> on download time and required disk space, right? It does not
> affect startup time at all.
Exactly. The only thing that would affect startup time would be
modules that are actually use()d.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net
|