Thread: [Camelbones-devel] Framework-embedded Perl - what can be left out?
Brought to you by:
shermpendley
From: Sherm P. <she...@gm...> - 2010-12-12 21:57:02
|
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. There's obviously still work to be done on it, but it's a good start. The problem is, it's bloody huge... 81.9MB. Ever seen a morbidly obese camel? Let me tell ya, it ain't a pretty sight. :-) So, I'm thinking about what *needs* to be included in the framework for use at run time, and what can be left out. Note that the developer package will still include a complete copy of the same Perl build, installed in /Developer/CamelBones/Perl/. What I'm talking about here is the bare-bones minimum that needs to be included in CamelBones.framework for use at run time. Man pages are right out, already - that's what brings the size down to 82MB. First candidate for deletion is bin/ - that's 7.9MB, and I'm thinking that not too many apps that use the framework will *also* need all of those command-line tools. Even an app that does need a command line tool is unlikely to need *all* of them, and can copy just the one(s) it needs from /Developer/CamelBones/Perl/bin/. Next up is CORE/. That's headers and libperl.a, neither of which are needed at run time. Giving that the axe saves us another 14.9MB. Then - pods/. Those are for developers, and useless baggage at run time. That saves 6.8MB. 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 40-60MB .app bundle looks fairly typical, and quite a few weigh in at 100-150MB. iMovie and OpenOffice.Org are both over 400MB. Unity 3D is the biggest .app on my system, at 548MB. One additional thing worth considering is that most of that is Perl code, which compresses quite well. 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? sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: Thilo P. <thi...@go...> - 2010-12-13 01:48:52
|
> 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). A 15 MB download and a 53 MB application bundle may be unfortunate, but really not a problem, I think. That should be good enough for the 2.0 release. 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? How big is the bundle when you delete all Perl modules? (That would not leave the embedded Perl functional, but just to get an upper bound on the potential savings here). 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. Cheers, Thilo |
From: Sherm P. <she...@gm...> - 2010-12-13 04:28:19
|
On Sun, Dec 12, 2010 at 8:48 PM, Thilo Planz <thi...@go...> 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 |
From: Pedro M. <me...@si...> - 2010-12-13 07:04:23
|
Hi, On Mon, Dec 13, 2010 at 4:28 AM, Sherm Pendley <she...@gm...> wrote: > 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. Yeah, this was what I was thinking. I think the default at 53MB is good enough. Those who are concern can remove the core pm files they don't need. >> 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. See App::staticperl on CPAN for the latest method to build a standalone micro perl. It might not translate directly to CamelBones, but I'm sure you'll find interesting code in there that might help you. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:me...@si... mailto:me...@si... |
From: Pedro M. <me...@si...> - 2010-12-13 07:16:33
|
Hi, On Sun, Dec 12, 2010 at 9:56 PM, Sherm Pendley <she...@gm...> wrote: > 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 40-60MB .app bundle looks fairly typical, > and quite a few weigh in at 100-150MB. iMovie and OpenOffice.Org are > both over 400MB. Unity 3D is the biggest .app on my system, at 548MB. > > One additional thing worth considering is that most of that is Perl > code, which compresses quite well. A .zip archive of the framework is > only 14.9MB, which IMHO is quite reasonable for a download, even for > someone on dialup. Can you break down these last 53MB? What is the split between libperl and .pm/.pl files? If the majority is .pm/.pl files then a small tool to remove unused files per project would be enough. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:me...@si... mailto:me...@si... |
From: Sherm P. <she...@gm...> - 2010-12-13 13:56:27
|
On Mon, Dec 13, 2010 at 1:55 AM, Pedro Melo <me...@si...> wrote: > > On Mon, Dec 13, 2010 at 4:28 AM, Sherm Pendley <she...@gm...> wrote: >> 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. > > Yeah, this was what I was thinking. > > I think the default at 53MB is good enough. Those who are concern can > remove the core pm files they don't need. Another option would be to include a shell script build phase in app templates, that copied all of the useful core files by default, and a main.pl that included the above scheme to report "unbundled" files. Simply removing (or commenting) the default shell script would then generate a list of modules that were actually used by the app. > See App::staticperl on CPAN for the latest method to build a > standalone micro perl. It might not translate directly to CamelBones, > but I'm sure you'll find interesting code in there that might help > you. Thanks - I'll check it out. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: Sherm P. <she...@gm...> - 2010-12-15 02:22:08
|
On Mon, Dec 13, 2010 at 8:56 AM, Sherm Pendley <she...@gm...> wrote: > > Another option would be to include a shell script build phase in app > templates, that copied all of the useful core files by default, and a > main.pl that included the above scheme to report "unbundled" files. > Simply removing (or commenting) the default shell script would then > generate a list of modules that were actually used by the app. Thinking this through a bit more, I like this option. Including the Perl modules in the framework would bulk up the developer package for no good reason. They're going to get copied into the .app bundle one way or another, either as part of the framework or in a separate build phase, so nothing is gained by keeping an extra copy of them around. What's more, copying the modules as part of the framework, only to immediately delete some of them, would be wasteful. It would also be a potential source of errors, as the build phase that removed unneeded modules could only be run *after* the copy files build phase that copied the framework. If the modules are simply copied into the .app bundle, it wouldn't matter if that happens before or after the framework is copied. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: Will C. <wi...@co...> - 2010-12-13 13:56:44
|
On Sun, Dec 12, 2010 at 4:56 PM, Sherm Pendley <she...@gm...> 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. There's obviously still work > to be done on it, but it's a good start. > > The problem is, it's bloody huge... 81.9MB. Ever seen a morbidly obese > camel? Let me tell ya, it ain't a pretty sight. :-) > > So, I'm thinking about what *needs* to be included in the framework > for use at run time, and what can be left out. Note that the developer > package will still include a complete copy of the same Perl build, > installed in /Developer/CamelBones/Perl/. What I'm talking about here > is the bare-bones minimum that needs to be included in > CamelBones.framework for use at run time. > > Man pages are right out, already - that's what brings the size down to 82MB. > > First candidate for deletion is bin/ - that's 7.9MB, and I'm thinking > that not too many apps that use the framework will *also* need all of > those command-line tools. Even an app that does need a command line > tool is unlikely to need *all* of them, and can copy just the one(s) > it needs from /Developer/CamelBones/Perl/bin/. > > Next up is CORE/. That's headers and libperl.a, neither of which are > needed at run time. Giving that the axe saves us another 14.9MB. > > Then - pods/. Those are for developers, and useless baggage at run > time. That saves 6.8MB. > > 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 40-60MB .app bundle looks fairly typical, > and quite a few weigh in at 100-150MB. iMovie and OpenOffice.Org are > both over 400MB. Unity 3D is the biggest .app on my system, at 548MB. > > One additional thing worth considering is that most of that is Perl > code, which compresses quite well. 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? > > sherm-- > > -- > Cocoa programming in Perl: > http://camelbones.sourceforge.net > > ------------------------------------------------------------------------------ > Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, > new data types, scalar functions, improved concurrency, built-in packages, > OCI, SQL*Plus, data movement tools, best practices and more. > http://p.sf.net/sfu/oracle-sfdev2dev > _______________________________________________ > Camelbones-devel mailing list > Cam...@li... > https://lists.sourceforge.net/lists/listinfo/camelbones-devel > This topic recently came up on the perl5-porters list. http://www.nntp.perl.org/group/perl.perl5.porters/2010/11/msg166097.html Might be worth raising this question over there, too. -- Will "Coke" Coleda |
From: Matt S. <ma...@se...> - 2010-12-13 16:55:08
|
On Sun, 12 Dec 2010, Sherm Pendley 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. There's obviously still work > to be done on it, but it's a good start. > > The problem is, it's bloody huge... 81.9MB. Ever seen a morbidly obese > camel? Let me tell ya, it ain't a pretty sight. :-) [snippety snip] Remember that on the plus side, the PAR files will be smaller as there will only be one version in them. Matt. |
From: Sherm P. <she...@gm...> - 2010-12-13 19:27:26
|
On Mon, Dec 13, 2010 at 11:55 AM, Matt Sergeant <ma...@se...> wrote: > > Remember that on the plus side, the PAR files will be smaller as there will > only be one version in them. True! With only one version & arch to support, those should be roughly a third of their current size. And, PAR archives can also easily be trimmed of unneeded modules. They're really just .zip files, so there are plenty of tools (including Finder) one can use to manage their contents. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |