base.im questions
Locked
12
12
 
|
I have some questions about base.im.
1) Why is this still in preview? 2) This file used to be about 8MB (which is still pretty big if you ask me). Now it is 15MB? It is barely smaller than visual.im. Can we please try to make this smaller? 3) Is there a simple class browser and debugger that can be loaded into this image? Thanks, -Carl Gundel http://www.libertybasic.com http://www.runbasic.com _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
1) It's still in preview
because we haven't done the work to really consider it production-level.
Although we do use it as part of our own build process, so there's an
argument it could be considered production-level on the basis of working
well enough. We're not particularly happy with the amount it is smaller
than visual.im either, but the work to improve it hasn't been done.
2) It was about 8MB in 7.3, at which point it was 3.4MB smaller than visual.im. In 7.8.1 it is 16MB, and visual.im is 19M. So it's about the same amount smaller than visual.im that it ever was, which is not surprising, because it's just visual.im with the tools unloaded. There are additional things we could do to make it smaller, but they tend to be complicated, involving untangling the mess of dependencies inside Base VisualWorks, where the packages were initially created just based on class categories, rather than any partitioning by dependencies. While some work on that does get done, getting it done thoroughly hasn't been a high enough priority compared to other things people have asked for to make it happen. And lots of the things that people ask for end up adding things to the base. Probably the biggest single factor in the image growing is the removal of short compiled methods, an optimization for representing simple method bytecodes in a small integer, but one which did not work in 64-bit. There are some options for getting that space, or even possibly more, back again, but again, there have been higher priorities. If you'd like to try and raise the priorities of things, Arden Thomas is the person to talk to. 3) It is possible to load "Tools-Old Debugger" and "OldBrowsers". You might have to do a bit of work to get them to work, but they should, I think, be basically functional. I presume you're not looking to just load the regular browser and debugger, at which point you'd essentially have visual.im.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Carl Gundel-2
"Alan Knight"<[hidden email]> wrote:
> Probably the biggest single factor in the image growing is the removal > of short compiled methods, an optimization for representing simple > method bytecodes in a small integer, but one which did not work in > 64-bit. There are some options for getting that space, or even possibly > more, back again, but again, there have been higher priorities. If you'd > like to try and raise the priorities of things, Arden Thomas is the > person to talk to. IIRC the measured overhead of abandoning short-compiled code was sub 1M, but there were other things that added up, like importing the full set of Locales, etc. Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Good point. Martin has a
better memory than I do :-)
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
I'm thinking that there's a ton of stuff in there that Liberty BASIC
will never touch. I hope I can get the final image size down to 5MB or so. Is there a strategy using the Runtime Packager which will get me there? Do I need to write my own stripper? Any advice appreciated. Thanks, -Carl Gundel http://www.libertybasic.com http://www.runbasic.com On Mon, Jan 16, 2012 at 11:38 AM, Alan Knight <[hidden email]> wrote: > Good point. Martin has a better memory than I do :-) > > ________________________________ > > [hidden email] > 16 January, 2012 11:34 AM > > > > IIRC the measured overhead of abandoning short-compiled code was sub 1M, but > there were other things that added up, like importing the full set of > Locales, etc. > > Martin vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
I'd still say you're better off not using the RTP approach; trying to pull unused methods and classes (as opposed to whole packages) gains you very little at the cost of pretty high uncertainty.
-- start with visual.im -- load your parcels -- use script like this to unload: (Store.Registry pundleNamed: #('PackageNameHere')) ifNotNil: [:pundle | pundle leafItems do: [:each | each markNotModified]. [pundle markNotModified; unloadFromImage] on: [Warning do: [:ex | ex resume: true]]. I'm sure there's an equivalent for images w/o Store loaded, but my builder starts from a Store image. The larger point is this: unloading packages and bundles removes large amounts of stuff; unloading classes and methods, not so much. On Jan 16, 2012, at 12:41 PM, Carl Gundel wrote: > I'm thinking that there's a ton of stuff in there that Liberty BASIC > will never touch. I hope I can get the final image size down to 5MB > or so. Is there a strategy using the Runtime Packager which will get > me there? Do I need to write my own stripper? > > Any advice appreciated. > > Thanks, > > -Carl Gundel > http://www.libertybasic.com > http://www.runbasic.com > > On Mon, Jan 16, 2012 at 11:38 AM, Alan Knight <[hidden email]> wrote: >> Good point. Martin has a better memory than I do :-) >> >> ________________________________ >> >> [hidden email] >> 16 January, 2012 11:34 AM >> >> >> >> IIRC the measured overhead of abandoning short-compiled code was sub 1M, but >> there were other things that added up, like importing the full set of >> Locales, etc. >> >> Martin > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc James Robertson http://www.jarober.com [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
On Jan 16, 2012, at 11:40 AM, James Robertson wrote: > I'd still say you're better off not using the RTP approach; trying to pull unused methods and classes (as opposed to whole packages) gains you very little at the cost of pretty high uncertainty. > > -- start with visual.im > -- load your parcels > -- use script like this to unload: > > (Store.Registry pundleNamed: #('PackageNameHere')) ifNotNil: [:pundle | > pundle leafItems do: [:each | each markNotModified]. > [pundle markNotModified; unloadFromImage] on: [Warning do: [:ex | ex resume: true]]. > > I'm sure there's an equivalent for images w/o Store loaded, but my builder starts from a Store image. The larger point is this: unloading packages and bundles removes large amounts of stuff; unloading classes and methods, not so much. I concur with this. Build up. But I think, Carl's issue is that the foundation he's building up from seems a little bit of overkill. I wouldn't personally use RTP to try and address this problem. My hunch is that there's some rather large low hanging fruit that you can remove with a couple of workspace/script like expressions. My bet, personally, is along the same lines as Martin's comment. The primary addition to image size seems to have been collation and locale stuff. On my image for example, the following expression: ObjectMemory current numOopsNumBytesIn: PrintFormatToken allGeneralInstances indicates there are ~57000 instances chewing up 1.35 MB of memory. I'm guessing I don't need that many instances of PrintFormatTokens to do my every day job. -- Travis Griggs Objologist Simplicity is the Ultimate Sophistication -- Leonardo da Vinci _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Carl Gundel-2
Oops! 5 MB? I don't want to discourage you, but that's a challenge!
I have a small application (email spam killer without any GUI, just using the email support parcels and some application code). For some time I made a sport of it to reduce the runtime image size. The dev image was 16.921.384 Bytes and with some effort I arrived at 7.367.660 Bytes for the RT. Ok, coward as I am, I avoided the painful "scan unreferenced" step. My approach was finding out the redundant parcels/packages and then unload as much as possible on that level. This gives a highly reliable and reproducible result. "Real men" :-) will go ahead and let RuntimePackager find more death candidates and kill them. But in lots of *my* projects I found that this does not pay off. The result is a bit unpredictable, you never know what RuntimePackager deletes and often enough it killed some code that I needed. The risk of getting the good guys shot is increasing while the benefit of image size reduction is shrinking. I think that RuntimePackager is a good tool and I like to use it. If you "do it right" and in particular specify correctly what you need to keep, you will succeed in best reduction with the required code surviving in the image. But the "doing it right" requires learning. In face of ever growing storage devices and bandwidth it's hard to justify too much development effort for saving 1 MB or 2. The same argument made me stop the quest for more reduction. Sure, there are some candidates that could be pushed out of the image with modest effort. And the "scan unreferenced" should at least be tried a couple of times. And I could do the image compression procedure. But after all, small size is no real requirement for me and/or this tool. In the case of our base.im I gave it a try and extracted a parcel table-of-contents report which shows a lot of Store stuff, all from parcel PackageCategories. Could be worth to look at... And Martin's hint is good. Wasn't there a post here claiming that Locale objects populate the image and occupy much memory? Regards Holger Guhl -- Senior Consultant * Certified Scrum Master * [hidden email] Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812 Am 16.01.2012 18:41, schrieb Carl Gundel: > I'm thinking that there's a ton of stuff in there that Liberty BASIC > will never touch. I hope I can get the final image size down to 5MB > or so. Is there a strategy using the Runtime Packager which will get > me there? Do I need to write my own stripper? > > Any advice appreciated. > > Thanks, > > -Carl Gundel > http://www.libertybasic.com > http://www.runbasic.com > > On Mon, Jan 16, 2012 at 11:38 AM, Alan Knight<[hidden email]> wrote: >> Good point. Martin has a better memory than I do :-) >> >> ________________________________ >> >> [hidden email] >> 16 January, 2012 11:34 AM >> >> >> >> IIRC the measured overhead of abandoning short-compiled code was sub 1M, but >> there were other things that added up, like importing the full set of >> Locales, etc. >> >> Martin > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: base.im questions
|
|
In reply to this post by Carl Gundel-2
Carl,
Is your goal of 5MB before packaging\win\imagecompress.exe or after? Here's our earlier build from today to give you an idea of a ratio we're seeing, 39,929,760 raven.im 15,278,888 raven.compressed.im -Boris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Carl Gundel Sent: Monday, January 16, 2012 12:41 PM To: [hidden email] Subject: Re: [vwnc] base.im questions I'm thinking that there's a ton of stuff in there that Liberty BASIC will never touch. I hope I can get the final image size down to 5MB or so. Is there a strategy using the Runtime Packager which will get me there? Do I need to write my own stripper? Any advice appreciated. Thanks, -Carl Gundel http://www.libertybasic.com http://www.runbasic.com On Mon, Jan 16, 2012 at 11:38 AM, Alan Knight <[hidden email]> wrote: > Good point. Martin has a better memory than I do :-) > > ________________________________ > > [hidden email] > 16 January, 2012 11:34 AM > > > > IIRC the measured overhead of abandoning short-compiled code was sub > 1M, but there were other things that added up, like importing the full > set of Locales, etc. > > Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Travis Griggs-4
I agree with the overhead comments related to internationalization.
In the follow-on release to 7.9, whatever its name may be, I'd like to move to dynamic allocation of locale instances. This would cut down on this memory pressure.
Les From: [hidden email] on behalf of Travis Griggs Sent: Mon 1/16/2012 12:58 PM To: James Robertson; VWNC NC Subject: Re: [vwnc] base.im questions On Jan 16, 2012, at 11:40 AM, James Robertson wrote: _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Travis Griggs-4
I don't think he's going
to get that kind of size by building up. Clearly not with what he has to
build up from right now, but to get to a 5MB size of a base would be
quite a significant reduction. And Runtime Packager, in addition to
deleting code, does a number of other reasonably clever things. So I'd
say you probably want to look at
- big chunks of stuff you don't need - so pruning lots and lots of locale stuff might work. PackageCategories was mentioned - if you don't need packages as entities at runtime you can get rid of that and of the instances it keeps around (which probably would involve scripting that). If you don't need parcel loading, you can get rid of it and any parcels represented in the image. If you only care about one platform you can get rid of all the other look and feel code. Runtime packager does this, but it may not be doing it as thoroughly as entirely unloading the packages would, I'm not sure. There are things in Base VisualWorks like Tools, some of which might be things you want at runtime (e.g. hover help) but others you won't, like MethodCollector and AboutVisualWorksDialog. Examples can probably go. XML can probably go. etc. But of course once XML goes you can't read source, which makes it harder to debug. And so on. - look at what runtime packager is doing, see if there are places you can apply it further. One thing that takes up space is previously existing objects. That includes things like fonts and windows. So when you do a save, it might be worthwhile to start up again headless, do a complete garbage collect, and then save. This is similar what RTP does in its three-step save process, but there it's worrying about permspace, and doesn't do it headless.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
In reply to this post by Carl Gundel-2
Author Said: "Alan Knight" <[hidden email]> |
@+Maarten, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by jarober
James Robertson wrote:
> I'd still say you're better off not using the RTP approach; trying to > pull unused methods and classes (as opposed to whole packages) gains > you very little at the cost of pretty high uncertainty. > > (Store.Registry pundleNamed: #('PackageNameHere')) ifNotNil: [:pundle | > pundle leafItems do: [:each | each markNotModified]. > [pundle markNotModified; unloadFromImage] on: [Warning do: > [:ex | ex resume: true]]. If I use RTP to remove stuff, at least it performs some checks for me whether that stuff is used. Just bulk unloading packages gives far more uncertainty - you'll often find there's some extension method there that you've used without realizing it's not in the base. But if you do want to unload whole packages or parcels, RTP makes that easy too. RTP is a lot more usable since it moved from categories to Store concepts. If you care about making your image small, I'd say it's the best thing out there. We do some light scripting first to unload obvious dev tools packages, tell RTP which are our packages to keep, and let RTP figure out which extension methods etc. we use. There are a few extra Cincom packages or classes where we need to tell RTP to keep them, because it can't figure out the meta-programming paths by which they are used, but those stay stable for a long time - maybe just one or two changes for each VW version. Steve _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Yes and no. We ran into that problem for about a week when we started using this approach, and then we stopped running into it. What caused us more heartburn were the ongoing "it stripped the wrong thing" aspect of RTP, which happens unless you babysit it.
On Jan 17, 2012, at 6:13 AM, Steven Kelly wrote: > James Robertson wrote: >> I'd still say you're better off not using the RTP approach; trying to >> pull unused methods and classes (as opposed to whole packages) gains >> you very little at the cost of pretty high uncertainty. >> >> (Store.Registry pundleNamed: #('PackageNameHere')) ifNotNil: [:pundle > | >> pundle leafItems do: [:each | each markNotModified]. >> [pundle markNotModified; unloadFromImage] on: [Warning do: >> [:ex | ex resume: true]]. > > If I use RTP to remove stuff, at least it performs some checks for me > whether that stuff is used. Just bulk unloading packages gives far more > uncertainty - you'll often find there's some extension method there that > you've used without realizing it's not in the base. But if you do want > to unload whole packages or parcels, RTP makes that easy too. > > RTP is a lot more usable since it moved from categories to Store > concepts. If you care about making your image small, I'd say it's the > best thing out there. We do some light scripting first to unload obvious > dev tools packages, tell RTP which are our packages to keep, and let RTP > figure out which extension methods etc. we use. There are a few extra > Cincom packages or classes where we need to tell RTP to keep them, > because it can't figure out the meta-programming paths by which they are > used, but those stay stable for a long time - maybe just one or two > changes for each VW version. > > Steve > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc James Robertson http://www.jarober.com [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Travis Griggs-4
Thanks. It's amazing there are so many of these. How do I remove
them? Do I need a script or is there a tool for adding/removing these? If I do remove them, how do I know which ones I should keep? I know I'm going to want to keep the US related ones, and perhaps there are EU locales too? -Carl On Mon, Jan 16, 2012 at 3:58 PM, Travis Griggs <[hidden email]> wrote: > > On Jan 16, 2012, at 11:40 AM, James Robertson wrote: > >> I'd still say you're better off not using the RTP approach; trying to pull unused methods and classes (as opposed to whole packages) gains you very little at the cost of pretty high uncertainty. >> >> -- start with visual.im >> -- load your parcels >> -- use script like this to unload: >> >> (Store.Registry pundleNamed: #('PackageNameHere')) ifNotNil: [:pundle | >> pundle leafItems do: [:each | each markNotModified]. >> [pundle markNotModified; unloadFromImage] on: [Warning do: [:ex | ex resume: true]]. >> >> I'm sure there's an equivalent for images w/o Store loaded, but my builder starts from a Store image. The larger point is this: unloading packages and bundles removes large amounts of stuff; unloading classes and methods, not so much. > > > I concur with this. Build up. > > But I think, Carl's issue is that the foundation he's building up from seems a little bit of overkill. I wouldn't personally use RTP to try and address this problem. My hunch is that there's some rather large low hanging fruit that you can remove with a couple of workspace/script like expressions. > > My bet, personally, is along the same lines as Martin's comment. The primary addition to image size seems to have been collation and locale stuff. On my image for example, the following expression: > > ObjectMemory current numOopsNumBytesIn: PrintFormatToken allGeneralInstances > > indicates there are ~57000 instances chewing up 1.35 MB of memory. I'm guessing I don't need that many instances of PrintFormatTokens to do my every day job. > > -- > Travis Griggs > Objologist > Simplicity is the Ultimate Sophistication -- Leonardo da Vinci > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Maarten Mostert
It is not out of the question to script RTP; it just has some hurdles. I wrote a tool that incorporates a scripted combination of build-up and strip down:
$(VISUALWORKS)/contributed/PackingListTool.pcl
which was included with VW 7.6. Although I don't see the tool in later versions of the distribution, Cincom still seems to use the tool internally. I think some versions of the installer and packaging tool are in the public repository, if you don't have a copy of VW 7.6 laying around, but I can't be sure anymore. I don't have access to the public repository from here, and the static html public repository only lists "interesting" packages, not all.
As part of staging all the files for the distribution, install.im gets created using RTP. The starting point is PackingListTool>>makeInstallImage.
It starts by copying base.im to the target image filename. Then it generates a command line to start that image such that it loads requisite parcels (including the installer parcel) then initiates a strip with a command line doit:
VisualWorks.InstallImageStripper stripInstallImage: 'install.im'
InstallImageStripper class>>stripInstallImage: actually drives the RTP strip process through the first save of the 3-save process. Then the forked image quits, and the packaging tool initiates the next 2 saves.
[hidden email] From: "[hidden email]" <[hidden email]> To: VWNC NC <[hidden email]> Sent: Tue, January 17, 2012 2:50:02 AM Subject: Re: [vwnc] base.im questions Author Said: "Alan Knight" <[hidden email]> |
@+Maarten, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: base.im questions
|
|
We’ve been automating our RTP-based builds for years with the below as one of the steps. It would definitely be an improvement if we didn’t have to fake out UI interactions, but it’s a one-off pain of setting this up and flawless builds in the long run, so I’m not complaining much at the end of the day. | rtp wrap editor tree | RuntimePackager.RuntimeBuilderUI open. rtp := RuntimePackager.RuntimeBuilderUI activeApplication. rtp interactWithUser: false. wrap := Refactory.Wrappers.ConditionalMethodWrapper on: #requestFileName:default:version:ifFail: inClass: Dialog class alternative: [:a :b | (ObjectMemory imageDirectory construct: 'params.rtp') asString]. wrap condition: [:a :b | false]; install. [rtp loadParams] ensure: [wrap uninstall]. rtp keptItems edit. editor := rtp keptItems editor. tree := editor systemPackagesTree treeHolder tree. tree copy do: [:ea | tree expandFully: (tree indexOf: ea)]. self pundlesToInclude do: [:nm || subject | subject := (editor systemPackagesTree selectionAspect list detect: [:ea | ea value name = nm]) value. editor systemPackagesTree select: subject. editor keepSelectedPundle]. editor accept. wrap := Refactory.Wrappers.ConditionalMethodWrapper on: #confirm: inClass: Dialog class alternative: [:a :b | true]. wrap condition: [:a :b | false]; install. [rtp packageRuntimeImage] ensure: [wrap uninstall]. -Boris From: [hidden email] [mailto:[hidden email]] On Behalf Of Dave Stevenson It is not out of the question to script RTP; it just has some hurdles. I wrote a tool that incorporates a scripted combination of build-up and strip down: $(VISUALWORKS)/contributed/PackingListTool.pcl which was included with VW 7.6. Although I don't see the tool in later versions of the distribution, Cincom still seems to use the tool internally. I think some versions of the installer and packaging tool are in the public repository, if you don't have a copy of VW 7.6 laying around, but I can't be sure anymore. I don't have access to the public repository from here, and the static html public repository only lists "interesting" packages, not all. As part of staging all the files for the distribution, install.im gets created using RTP. The starting point is PackingListTool>>makeInstallImage. It starts by copying base.im to the target image filename. Then it generates a command line to start that image such that it loads requisite parcels (including the installer parcel) then initiates a strip with a command line doit: VisualWorks.InstallImageStripper stripInstallImage: 'install.im' InstallImageStripper class>>stripInstallImage: actually drives the RTP strip process through the first save of the 3-save process. Then the forked image quits, and the packaging tool initiates the next 2 saves. Dave Stevenson From: "[hidden email]" <[hidden email]> Author Said: "Alan Knight" <[hidden email]> |
@+Maarten, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Steven Kelly
James, I always thought of your simple packaging procedure as being fine
for toy programs and hobby applications. But not for professional software. It is true though: using RTP requires significant effort. My packaging process is: 1. parcel out all my runtime packages/bundles. 2. load my parcels (and other libraries) into the base.im 3. load RTP and set all parameters, including "parcels to unload" 4. run RTP with the 3-step save method 5. adding the compressed runtime.im to the VM with reshacker to get a single file executable All steps are automated by one procedure (actually methods containing configurations and batch writing methods) which can be triggered-off with one click. This is important, since operating the RTP manually via interface is far too error-prone to be reliable. EFFORT (one time): automate you packaging procedure. My modules have always one main bundle with one runtime bundle and additional stuff for development and testing. I take care of only having runtime relevant code in the runtime bundle. Sometimes I check the removed code report from the RTP to identify unused code - this is simple for top level code, but can be tricky for libraries. EFFORT (continuous): keep the runtime clean by maintaining the runtime/dev structure. RTP has the nice feature of declaring dynamically referenced classes and methods. This needs to be done for generic library code (including lots of VisualsWorks code - the developers seem to be not too aware of runtime and packaging issues). EFFORT (once for each VW release or when libraries are used for the first time): debug the packaging by trial-and-error until all missing method errors are resolved - this can be tricky. RTP lets you unload parcels before packaging. This works nicely for many parcels. But there are also bad examples - really bad is COM where no distinction between runtime and development is maintained, although the package names suggest differently. Without RTP it is not possible to remove anything from COM (several MB). Overall, I think that this effort is reasonable and the procedure is fine. A bit more support from Cincom would be appreciated, though. Some numbers all sizes in MB): Version base.im size my code size exe size 7.4.1 8.620 3.48 / - 5.408 / - 7.5 8.941 6.49 / - 5.912 / - 7.6 9.457 6.96 / 8.46 5.790 / 5.930 7.7 13.716 8.61 / 7.81 7.417 / 7.970 7.7.1 14.129 - / 51.1 - / 13.039 7.8 15.078 54.7 / 51.7 15.297 / 15.981 The size of my code (of two of my products) is not very meaningful, since I load other code as well. The exe size includes the VM. The base.im gets bigger with every release (jumped whooping 4 MB with the locales). PLEASE Cincom, invest a bit in cleaning the base.im. I want my single digit MB executables back... Cheers, Christian _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Carl Gundel-2
Okay, I wrote the following quick script a cleared 1.2MB from my
image. That's nice. Am I missing anything? If someone running a German language PC starts up my image am I going to get a runtime error? | allLocales methods keys | "remove locales" allLocales := LocaleLocalizationComponent classPool at: #LocaleDictionary. allLocales keys copy do: [ :k | (k ~= #en_US and: [ k ~= #C ]) ifTrue: [ allLocales removeKey: k ] ]. "remove locale installation methods" methods := LocaleLocalizationComponent class methodDictionary. keys := methods keys asOrderedCollection select: [ :k | (k indexOfString: 'install_') = 1 ]. keys remove: #install_en_US_Locale. keys remove: #install_C_Locale. keys do: [ :k | methods removeKey: k ]. -Carl On Tue, Jan 17, 2012 at 10:16 AM, Carl Gundel <[hidden email]> wrote: > Thanks. It's amazing there are so many of these. How do I remove > them? Do I need a script or is there a tool for adding/removing > these? If I do remove them, how do I know which ones I should keep? > I know I'm going to want to keep the US related ones, and perhaps > there are EU locales too? > > -Carl > > On Mon, Jan 16, 2012 at 3:58 PM, Travis Griggs <[hidden email]> wrote: >> >> On Jan 16, 2012, at 11:40 AM, James Robertson wrote: >> >>> I'd still say you're better off not using the RTP approach; trying to pull unused methods and classes (as opposed to whole packages) gains you very little at the cost of pretty high uncertainty. >>> >>> -- start with visual.im >>> -- load your parcels >>> -- use script like this to unload: >>> >>> (Store.Registry pundleNamed: #('PackageNameHere')) ifNotNil: [:pundle | >>> pundle leafItems do: [:each | each markNotModified]. >>> [pundle markNotModified; unloadFromImage] on: [Warning do: [:ex | ex resume: true]]. >>> >>> I'm sure there's an equivalent for images w/o Store loaded, but my builder starts from a Store image. The larger point is this: unloading packages and bundles removes large amounts of stuff; unloading classes and methods, not so much. >> >> >> I concur with this. Build up. >> >> But I think, Carl's issue is that the foundation he's building up from seems a little bit of overkill. I wouldn't personally use RTP to try and address this problem. My hunch is that there's some rather large low hanging fruit that you can remove with a couple of workspace/script like expressions. >> >> My bet, personally, is along the same lines as Martin's comment. The primary addition to image size seems to have been collation and locale stuff. On my image for example, the following expression: >> >> ObjectMemory current numOopsNumBytesIn: PrintFormatToken allGeneralInstances >> >> indicates there are ~57000 instances chewing up 1.35 MB of memory. I'm guessing I don't need that many instances of PrintFormatTokens to do my every day job. >> >> -- >> Travis Griggs >> Objologist >> Simplicity is the Ultimate Sophistication -- Leonardo da Vinci >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Christian Haider
Is all that 4MB in the new locales? I managed to strip 1.2MB from my
image by using this script. Where's the other 2.8MB? | allLocales methods keys | "remove locales" allLocales := LocaleLocalizationComponent classPool at: #LocaleDictionary. allLocales keys copy do: [ :k | (k ~= #en_US and: [ k ~= #C ]) ifTrue: [ allLocales removeKey: k ] ]. "remove locale installation methods" methods := LocaleLocalizationComponent class methodDictionary. keys := methods keys asOrderedCollection select: [ :k | (k indexOfString: 'install_') = 1 ]. keys remove: #install_en_US_Locale. keys remove: #install_C_Locale. keys do: [ :k | methods removeKey: k ]. -Carl On Tue, Jan 17, 2012 at 10:47 AM, Christian Haider <[hidden email]> wrote: > James, I always thought of your simple packaging procedure as being fine > for toy programs and hobby applications. But not for professional > software. > > It is true though: using RTP requires significant effort. > > My packaging process is: > 1. parcel out all my runtime packages/bundles. > 2. load my parcels (and other libraries) into the base.im > 3. load RTP and set all parameters, including "parcels to unload" > 4. run RTP with the 3-step save method > 5. adding the compressed runtime.im to the VM with reshacker to get a > single file executable > > All steps are automated by one procedure (actually methods containing > configurations and batch writing methods) which can be triggered-off > with one click. > This is important, since operating the RTP manually via interface is far > too error-prone to be reliable. > EFFORT (one time): automate you packaging procedure. > > My modules have always one main bundle with one runtime bundle and > additional stuff for development and testing. I take care of only having > runtime relevant code in the runtime bundle. Sometimes I check the > removed code report from the RTP to identify unused code - this is > simple for top level code, but can be tricky for libraries. > EFFORT (continuous): keep the runtime clean by maintaining the > runtime/dev structure. > > RTP has the nice feature of declaring dynamically referenced classes and > methods. This needs to be done for generic library code (including lots > of VisualsWorks code - the developers seem to be not too aware of > runtime and packaging issues). > EFFORT (once for each VW release or when libraries are used for the > first time): debug the packaging by trial-and-error until all missing > method errors are resolved - this can be tricky. > > RTP lets you unload parcels before packaging. This works nicely for many > parcels. But there are also bad examples - really bad is COM where no > distinction between runtime and development is maintained, although the > package names suggest differently. Without RTP it is not possible to > remove anything from COM (several MB). > > Overall, I think that this effort is reasonable and the procedure is > fine. > A bit more support from Cincom would be appreciated, though. > > Some numbers all sizes in MB): > Version base.im size my code size exe size > 7.4.1 8.620 3.48 / - 5.408 / - > 7.5 8.941 6.49 / - 5.912 / - > 7.6 9.457 6.96 / 8.46 5.790 / 5.930 > 7.7 13.716 8.61 / 7.81 7.417 / 7.970 > 7.7.1 14.129 - / 51.1 - / 13.039 > 7.8 15.078 54.7 / 51.7 15.297 / 15.981 > > The size of my code (of two of my products) is not very meaningful, > since I load other code as well. > The exe size includes the VM. > > The base.im gets bigger with every release (jumped whooping 4 MB with > the locales). > PLEASE Cincom, invest a bit in cleaning the base.im. > I want my single digit MB executables back... > > Cheers, > Christian > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |