Parcel load times

> Hi all,
>
> There's been plenty of hot discussions about parcel's and their
> loading speed on this list before.. so I thought I'd throw in some
> hard data to help out.
>
> I've got a spreadsheet that shows the load time of 'base parcels' -
> parcels that either come with VisualWorks or that rarely change.
> http://www.spiritshigh.com/load-times.xls
>
> These parcels are included in the base image for SWS's XML
> WithStyle product. They add a hefty 5mb's of code to our base image
> (which compresses down to around 2.5mb when we make the .exe).
>
> "Patched" means that while loading the parcels, the following
> alteration is made to the parcel load logic:
>
> SystemUtils class>>modifySystem: aBlock
>             ^aBlock on: linkState do: [:ex | ex resume: false]
>
> This is undone at the end of the parcel loads and then 'SystemUtils
> linkSystem' is executed to ensure everything is linked up correctly.
>
> "Unpatched" means the parcels were loaded as per Cincom intended them,
> without any alterations to the system.
>
> On the second sheet there is a large graph showing the difference in
> the load times, but the "Speedup" column on the data sheet shows just
> how much of a difference the patch can sometimes make.
>
> Now, to really throw my spanner in to the works, I've shown the totals
> down the bottom. Even with the patch, it takes 21 seconds to load all
> these parcels. That's basically unacceptable for a desktop application
> :/. I've also included the time to load all of the parcels that have a
> reasonable speed up, excluding the ones that don't speed up. It still
> takes 7 seconds - that's on the "barely acceptable" edge of load
> times.
>
> I should point out that this is the base code, so on top of this the
> application code still has to load.
>
> The ultimate goal of the SRE and parcels, etc, was that a single small
> base image could load up all the parcels in a reasonable amount of
> time. We're not there yet obviously.
>
> With or without the patch loaded, the profile of loading all of these
> parcels is pretty consistent:
>
> 8.8% NameSpaceBindings>>lookup:
> 5.2% Object>>oneWayBecome:
> 3.8% Behavior>>bindingFor:
> 3.6% Behavior>>flushVMmethodCache
> 3.5% SequenceableCollection>>do:
> 3.0% GeneralNameSpace>>protectedBindingFor:modifiers:
> 2.8% Class>>protectedBindingFor:modifiers:
> 2.5% NameSpaceSearchRules>>forNames:do:
> 2.1% Set>>initialIndexFor:boundedBy:
> ... cut at 2.0%
>
> Basically, to be able to 'live the dream' and load all the parcels in
> at startup (with as few exceptions as possible), I'd need the
> parcel load code to be at least 2-3 times faster than my patched
> loader.
>
> If that could be achieved, I'd package with the slowest loading
> parcels included in the base. This would then mean by executable would
> be much smaller than it is now and 'online upgrades' wouldn't be as
> costly to my users bandwidth.
>
> Some other interesting facts: If you take the base.im or visual.im
> clean images and remove all the parcels, you end up with a 3mb image -
> this isn't too bad, as under compression this is around 1.5mb + the VM
> is 2mb-ish. That really -would- be an ideal executable size for a
> pluggable base application.
>
> Cheers,
> Michael
>

>> 8.8% NameSpaceBindings>>lookup:
>> 5.2% Object>>oneWayBecome:
>> 3.8% Behavior>>bindingFor:
>> 3.6% Behavior>>flushVMmethodCache
>> 3.5% SequenceableCollection>>do:
>> 3.0% GeneralNameSpace>>protectedBindingFor:modifiers:
>> 2.8% Class>>protectedBindingFor:modifiers:
>> 2.5% NameSpaceSearchRules>>forNames:do:
>> 2.1% Set>>initialIndexFor:boundedBy:
>> ... cut at 2.0%

> -----Original Message-----
> From: Michael Lucas-Smith [mailto:michael.lucas-
> [hidden email]]
> Sent: Monday, March 13, 2006 10:36 PM
> To: Charles A. Monteiro
> Cc: [hidden email]
> Subject: Re[2]: Parcel load times
>
> Yes it loads parcels just fine an' dandy. Actually with compression, I
> believe it'll be 1.5mb ish.. I can redo the experiment if you want and
> create scripts to make such an image.. are you interested?
>
> Cheers,
> Michael
>
> > Michael:
>
> > your wrote:
>
> >> Some other interesting facts: If you take the base.im or visual.im
> >> clean images and remove all the parcels, you end up with a 3mb

> > parcels?
>
> > -Charles
>
> > On Mon, 6 Mar 2006 10:50:07 +1100, Michael Lucas-Smith
> > <[hidden email]> wrote:
>
> >> Hi all,
>
> >> There's been plenty of hot discussions about parcel's and their
> >> loading speed on this list before.. so I thought I'd throw in some
> >> hard data to help out.
>
> >> I've got a spreadsheet that shows the load time of 'base parcels' -
> >> parcels that either come with VisualWorks or that rarely change.
> >> http://www.spiritshigh.com/load-times.xls
>
> >> These parcels are included in the base image for SWS's XML
> >> WithStyle product. They add a hefty 5mb's of code to our base image
> >> (which compresses down to around 2.5mb when we make the .exe).
>
> >> "Patched" means that while loading the parcels, the following
> >> alteration is made to the parcel load logic:
>
> >> SystemUtils class>>modifySystem: aBlock
> >>             ^aBlock on: linkState do: [:ex | ex resume: false]
>
> >> This is undone at the end of the parcel loads and then 'SystemUtils
> >> linkSystem' is executed to ensure everything is linked up

> >> parcels is pretty consistent:
>
> >> 8.8% NameSpaceBindings>>lookup:
> >> 5.2% Object>>oneWayBecome:
> >> 3.8% Behavior>>bindingFor:
> >> 3.6% Behavior>>flushVMmethodCache
> >> 3.5% SequenceableCollection>>do:
> >> 3.0% GeneralNameSpace>>protectedBindingFor:modifiers:
> >> 2.8% Class>>protectedBindingFor:modifiers:
> >> 2.5% NameSpaceSearchRules>>forNames:do:
> >> 2.1% Set>>initialIndexFor:boundedBy:
> >> ... cut at 2.0%
>
> >> Basically, to be able to 'live the dream' and load all the parcels

> CONFIDENTIALITY NOTICE
> Unless otherwise indicated this email contains information that is
> private
> and confidential. If you have received it in error, please notify the
> sender
> and delete this message along with any attachments.
>> -----Original Message-----
>> From: Michael Lucas-Smith [mailto:michael.lucas-
>> [hidden email]]
>> Sent: Monday, March 13, 2006 10:36 PM
>> To: Charles A. Monteiro
>> Cc: [hidden email]
>> Subject: Re[2]: Parcel load times
>>
>> Yes it loads parcels just fine an' dandy. Actually with compression, I
>> believe it'll be 1.5mb ish.. I can redo the experiment if you want and
>> create scripts to make such an image.. are you interested?
>>
>> Cheers,
>> Michael
>>
>> > Michael:
>>
>> > your wrote:
>>
>> >> Some other interesting facts: If you take the base.im or visual.im
>> >> clean images and remove all the parcels, you end up with a 3mb
> image -
>> >> this isn't too bad, as under compression this is around 1.5mb + the
> VM
>> >> is 2mb-ish. That really -would- be an ideal executable size for a
>> >> pluggable base application.
>>
>> > Do you actually have a base image i.e. a 3mb image which still can
> load
>> > parcels?
>>
>> > -Charles
>>
>> > On Mon, 6 Mar 2006 10:50:07 +1100, Michael Lucas-Smith
>> > <[hidden email]> wrote:
>>
>> >> Hi all,
>>
>> >> There's been plenty of hot discussions about parcel's and their
>> >> loading speed on this list before.. so I thought I'd throw in some
>> >> hard data to help out.
>>
>> >> I've got a spreadsheet that shows the load time of 'base parcels' -
>> >> parcels that either come with VisualWorks or that rarely change.
>> >> http://www.spiritshigh.com/load-times.xls
>>
>> >> These parcels are included in the base image for SWS's XML
>> >> WithStyle product. They add a hefty 5mb's of code to our base image
>> >> (which compresses down to around 2.5mb when we make the .exe).
>>
>> >> "Patched" means that while loading the parcels, the following
>> >> alteration is made to the parcel load logic:
>>
>> >> SystemUtils class>>modifySystem: aBlock
>> >>             ^aBlock on: linkState do: [:ex | ex resume: false]
>>
>> >> This is undone at the end of the parcel loads and then 'SystemUtils
>> >> linkSystem' is executed to ensure everything is linked up
> correctly.
>>
>> >> "Unpatched" means the parcels were loaded as per Cincom intended
> them,
>> >> without any alterations to the system.
>>
>> >> On the second sheet there is a large graph showing the difference
> in
>> >> the load times, but the "Speedup" column on the data sheet shows
> just
>> >> how much of a difference the patch can sometimes make.
>>
>> >> Now, to really throw my spanner in to the works, I've shown the
> totals
>> >> down the bottom. Even with the patch, it takes 21 seconds to load
> all
>> >> these parcels. That's basically unacceptable for a desktop
> application
>> >> :/. I've also included the time to load all of the parcels that
> have a
>> >> reasonable speed up, excluding the ones that don't speed up. It
> still
>> >> takes 7 seconds - that's on the "barely acceptable" edge of load
>> >> times.
>>
>> >> I should point out that this is the base code, so on top of this
> the
>> >> application code still has to load.
>>
>> >> The ultimate goal of the SRE and parcels, etc, was that a single
> small
>> >> base image could load up all the parcels in a reasonable amount of
>> >> time. We're not there yet obviously.
>>
>> >> With or without the patch loaded, the profile of loading all of
> these
>> >> parcels is pretty consistent:
>>
>> >> 8.8% NameSpaceBindings>>lookup:
>> >> 5.2% Object>>oneWayBecome:
>> >> 3.8% Behavior>>bindingFor:
>> >> 3.6% Behavior>>flushVMmethodCache
>> >> 3.5% SequenceableCollection>>do:
>> >> 3.0% GeneralNameSpace>>protectedBindingFor:modifiers:
>> >> 2.8% Class>>protectedBindingFor:modifiers:
>> >> 2.5% NameSpaceSearchRules>>forNames:do:
>> >> 2.1% Set>>initialIndexFor:boundedBy:
>> >> ... cut at 2.0%
>>
>> >> Basically, to be able to 'live the dream' and load all the parcels
> in
>> >> at startup (with as few exceptions as possible), I'd need the
>> >> parcel load code to be at least 2-3 times faster than my patched
>> >> loader.
>>
>> >> If that could be achieved, I'd package with the slowest loading
>> >> parcels included in the base. This would then mean by executable
> would
>> >> be much smaller than it is now and 'online upgrades' wouldn't be as
>> >> costly to my users bandwidth.
>>
>> >> Some other interesting facts: If you take the base.im or visual.im
>> >> clean images and remove all the parcels, you end up with a 3mb
> image -
>> >> this isn't too bad, as under compression this is around 1.5mb + the
> VM
>> >> is 2mb-ish. That really -would- be an ideal executable size for a
>> >> pluggable base application.
>>
>> >> Cheers,
>> >> Michael
>>
>>
>>

> -----Ursprüngliche Nachricht-----
> Von: Carl Gundel [mailto:[hidden email]]
> Gesendet: Dienstag, 14. März 2006 15:06
> An: [hidden email]
> Betreff: [7.4][Pollock]What close method?
>
>
> I'm using the latest published version of Pollock.  I have a
> subclass of
> UserInterface and I wanted to tweak the behavior of the close
> method.  Just
> to start I overrode close in UserInterface and put a
> breakpoint in it, but
> my method doesn't seem to get invoked when I close the window
> using the
> mouse or keyboard.  So I put a breakpoint in the close method on my
> UserInterface subclass' windowClass (a subclass of
> ApplicationWindow).  
> Nothing there either.
>
> What am I missing?
>
> -Carl Gundel, author of Liberty BASIC
> http://www.libertybasic.com
>
>
>

> Yes it loads parcels just fine an' dandy. Actually with compression, I  
> believe it'll be 1.5mb ish.. I can redo the experiment if you want and  
> create scripts to make such an image.. are you interested?
>
> Cheers,
> Michael
>
>> Michael:
>
>> your wrote:
>
>>> Some other interesting facts: If you take the base.im or visual.im
>>> clean images and remove all the parcels, you end up with a 3mb image -
>>> this isn't too bad, as under compression this is around 1.5mb + the VM
>>> is 2mb-ish. That really -would- be an ideal executable size for a
>>> pluggable base application.
>
>> Do you actually have a base image i.e. a 3mb image which still can load
>> parcels?
>
>> -Charles
>
>> On Mon, 6 Mar 2006 10:50:07 +1100, Michael Lucas-Smith
>> <[hidden email]> wrote:
>
>>> Hi all,
>
>>> There's been plenty of hot discussions about parcel's and their
>>> loading speed on this list before.. so I thought I'd throw in some
>>> hard data to help out.
>
>>> I've got a spreadsheet that shows the load time of 'base parcels' -
>>> parcels that either come with VisualWorks or that rarely change.
>>> http://www.spiritshigh.com/load-times.xls
>
>>> These parcels are included in the base image for SWS's XML
>>> WithStyle product. They add a hefty 5mb's of code to our base image
>>> (which compresses down to around 2.5mb when we make the .exe).
>
>>> "Patched" means that while loading the parcels, the following
>>> alteration is made to the parcel load logic:
>
>>> SystemUtils class>>modifySystem: aBlock
>>>             ^aBlock on: linkState do: [:ex | ex resume: false]
>
>>> This is undone at the end of the parcel loads and then 'SystemUtils
>>> linkSystem' is executed to ensure everything is linked up correctly.
>
>>> "Unpatched" means the parcels were loaded as per Cincom intended them,
>>> without any alterations to the system.
>
>>> On the second sheet there is a large graph showing the difference in
>>> the load times, but the "Speedup" column on the data sheet shows just
>>> how much of a difference the patch can sometimes make.
>
>>> Now, to really throw my spanner in to the works, I've shown the totals
>>> down the bottom. Even with the patch, it takes 21 seconds to load all
>>> these parcels. That's basically unacceptable for a desktop application
>>> :/. I've also included the time to load all of the parcels that have a
>>> reasonable speed up, excluding the ones that don't speed up. It still
>>> takes 7 seconds - that's on the "barely acceptable" edge of load
>>> times.
>
>>> I should point out that this is the base code, so on top of this the
>>> application code still has to load.
>
>>> The ultimate goal of the SRE and parcels, etc, was that a single small
>>> base image could load up all the parcels in a reasonable amount of
>>> time. We're not there yet obviously.
>
>>> With or without the patch loaded, the profile of loading all of these
>>> parcels is pretty consistent:
>
>>> 8.8% NameSpaceBindings>>lookup:
>>> 5.2% Object>>oneWayBecome:
>>> 3.8% Behavior>>bindingFor:
>>> 3.6% Behavior>>flushVMmethodCache
>>> 3.5% SequenceableCollection>>do:
>>> 3.0% GeneralNameSpace>>protectedBindingFor:modifiers:
>>> 2.8% Class>>protectedBindingFor:modifiers:
>>> 2.5% NameSpaceSearchRules>>forNames:do:
>>> 2.1% Set>>initialIndexFor:boundedBy:
>>> ... cut at 2.0%
>
>>> Basically, to be able to 'live the dream' and load all the parcels in
>>> at startup (with as few exceptions as possible), I'd need the
>>> parcel load code to be at least 2-3 times faster than my patched
>>> loader.
>
>>> If that could be achieved, I'd package with the slowest loading
>>> parcels included in the base. This would then mean by executable would
>>> be much smaller than it is now and 'online upgrades' wouldn't be as
>>> costly to my users bandwidth.
>
>>> Some other interesting facts: If you take the base.im or visual.im
>>> clean images and remove all the parcels, you end up with a 3mb image -
>>> this isn't too bad, as under compression this is around 1.5mb + the VM
>>> is 2mb-ish. That really -would- be an ideal executable size for a
>>> pluggable base application.
>
>>> Cheers,
>>> Michael
>
>
>

> Hi Michael
>
> I'd be interested in this. One experiment I did once was start with the
> 7.3.1 beta base image add all the parcels we use and then add our
> parcel. The size of the result was only about 15% larger than our build
> via the RTP. So my thinking was to add a build menu item that will save
> a Pundle as a parcel and load it and any pre-reqs into a base image.
> This would be quite a nice alternative build mechanism.
>
> Joerg
>
> -----
> Joerg Beekmann
> DeepCove Labs
> 4th floor 595 Howe Street
> Vancouver, BC, V6C 2T5
> voice +1.604.689.0322
> fax   +1.604.689.0311
> [hidden email]
>
> CONFIDENTIALITY NOTICE
> Unless otherwise indicated this email contains information that is
> private
> and confidential. If you have received it in error, please notify the
> sender
> and delete this message along with any attachments.
>> -----Original Message-----
>> From: Michael Lucas-Smith [mailto:michael.lucas-
>> [hidden email]]
>> Sent: Monday, March 13, 2006 10:36 PM
>> To: Charles A. Monteiro
>> Cc: [hidden email]
>> Subject: Re[2]: Parcel load times
>>
>> Yes it loads parcels just fine an' dandy. Actually with compression, I
>> believe it'll be 1.5mb ish.. I can redo the experiment if you want and
>> create scripts to make such an image.. are you interested?
>>
>> Cheers,
>> Michael
>>
>> > Michael:
>>
>> > your wrote:
>>
>> >> Some other interesting facts: If you take the base.im or visual.im
>> >> clean images and remove all the parcels, you end up with a 3mb
> image -
>> >> this isn't too bad, as under compression this is around 1.5mb + the
> VM
>> >> is 2mb-ish. That really -would- be an ideal executable size for a
>> >> pluggable base application.
>>
>> > Do you actually have a base image i.e. a 3mb image which still can
> load
>> > parcels?
>>
>> > -Charles
>>
>> > On Mon, 6 Mar 2006 10:50:07 +1100, Michael Lucas-Smith
>> > <[hidden email]> wrote:
>>
>> >> Hi all,
>>
>> >> There's been plenty of hot discussions about parcel's and their
>> >> loading speed on this list before.. so I thought I'd throw in some
>> >> hard data to help out.
>>
>> >> I've got a spreadsheet that shows the load time of 'base parcels' -
>> >> parcels that either come with VisualWorks or that rarely change.
>> >> http://www.spiritshigh.com/load-times.xls
>>
>> >> These parcels are included in the base image for SWS's XML
>> >> WithStyle product. They add a hefty 5mb's of code to our base image
>> >> (which compresses down to around 2.5mb when we make the .exe).
>>
>> >> "Patched" means that while loading the parcels, the following
>> >> alteration is made to the parcel load logic:
>>
>> >> SystemUtils class>>modifySystem: aBlock
>> >>             ^aBlock on: linkState do: [:ex | ex resume: false]
>>
>> >> This is undone at the end of the parcel loads and then 'SystemUtils
>> >> linkSystem' is executed to ensure everything is linked up
> correctly.
>>
>> >> "Unpatched" means the parcels were loaded as per Cincom intended
> them,
>> >> without any alterations to the system.
>>
>> >> On the second sheet there is a large graph showing the difference
> in
>> >> the load times, but the "Speedup" column on the data sheet shows
> just
>> >> how much of a difference the patch can sometimes make.
>>
>> >> Now, to really throw my spanner in to the works, I've shown the
> totals
>> >> down the bottom. Even with the patch, it takes 21 seconds to load
> all
>> >> these parcels. That's basically unacceptable for a desktop
> application
>> >> :/. I've also included the time to load all of the parcels that
> have a
>> >> reasonable speed up, excluding the ones that don't speed up. It
> still
>> >> takes 7 seconds - that's on the "barely acceptable" edge of load
>> >> times.
>>
>> >> I should point out that this is the base code, so on top of this
> the
>> >> application code still has to load.
>>
>> >> The ultimate goal of the SRE and parcels, etc, was that a single
> small
>> >> base image could load up all the parcels in a reasonable amount of
>> >> time. We're not there yet obviously.
>>
>> >> With or without the patch loaded, the profile of loading all of
> these
>> >> parcels is pretty consistent:
>>
>> >> 8.8% NameSpaceBindings>>lookup:
>> >> 5.2% Object>>oneWayBecome:
>> >> 3.8% Behavior>>bindingFor:
>> >> 3.6% Behavior>>flushVMmethodCache
>> >> 3.5% SequenceableCollection>>do:
>> >> 3.0% GeneralNameSpace>>protectedBindingFor:modifiers:
>> >> 2.8% Class>>protectedBindingFor:modifiers:
>> >> 2.5% NameSpaceSearchRules>>forNames:do:
>> >> 2.1% Set>>initialIndexFor:boundedBy:
>> >> ... cut at 2.0%
>>
>> >> Basically, to be able to 'live the dream' and load all the parcels
> in
>> >> at startup (with as few exceptions as possible), I'd need the
>> >> parcel load code to be at least 2-3 times faster than my patched
>> >> loader.
>>
>> >> If that could be achieved, I'd package with the slowest loading
>> >> parcels included in the base. This would then mean by executable
> would
>> >> be much smaller than it is now and 'online upgrades' wouldn't be as
>> >> costly to my users bandwidth.
>>
>> >> Some other interesting facts: If you take the base.im or visual.im
>> >> clean images and remove all the parcels, you end up with a 3mb
> image -
>> >> this isn't too bad, as under compression this is around 1.5mb + the
> VM
>> >> is 2mb-ish. That really -would- be an ideal executable size for a
>> >> pluggable base application.
>>
>> >> Cheers,
>> >> Michael
>>
>>
>>

> I just conducted the experiment again to make sure I wasn't talking out  
> my ass ;)
>
> The final running image is 3,385kb
>
> This includes all the platform's UI's, so it really is a universal  
> image. It can load up a parcel on startup - but the startup code is  
> really up to you to do how you want it.. fixed parcel name? command line  
> parameter? etc...
>
> I start from visual.im which is 11,078kb using VisualWorks 7.4
>
> I then run the following script:
>
> | packages bundles |
> Tools.Workbook allInstances do: [:each | each closeAndUnschedule].
> packages := Store.PackageModel allInstances select: [:ea |  
> #( 'OldBrowsers' 'Tools-Trippy' 'Tools-Workspace' 'Tools-Changes'  
> 'Tools-Parcel Manager' 'Tools-File Browser' ) includes: ea name].
> bundles := Store.BundleModel allInstances select: [:ea |  
> #( 'Tools-Debugger' 'Tools-Refactoring Browser' ) includes: ea name].
> [(bundles asSortedCollection: [:a :b | a name < b name]) do: [:each |  
> each unloadFromImage].
> (packages asSortedCollection: [:a :b | a name < b name]) do: [:each |  
> each unloadFromImage]]
> on: Warning do: [:sig | sig resume: true]
>
> If you save the image at this point, it will be 8,422kb - the base.im  
> that comes in the preview\packaging directory is 8,604kb so already  
> we're winning ;)
>
> Then if you use the RuntimePackager with -ALL DEFAULT SETTINGS- except  
> that I also use compacted compiled methods, you end up with a runtime.im  
> that is 7,500kb.
>
> I then run imageCompress against it and I end up with a compressed.im  
> that is the final size of 3,385kb
>
> Naturally, this could be taken further - the VW settings could be  
> removed, the launcher could be removed, etc.. but the producer is very  
> easy at this point and you can still actually -use- the shrunken image  
> if you want.
>
> So! Have at it all.. is this a good way to make a base? I personally  
> think so. If you whack the windows VM .exe on to it, you end up with a  
> base executable that is 4,006kb.
>
> Not bad really.
>
> Cheers,
> Michael
>
>> Hi Michael
>
>> I'd be interested in this. One experiment I did once was start with the
>> 7.3.1 beta base image add all the parcels we use and then add our
>> parcel. The size of the result was only about 15% larger than our build
>> via the RTP. So my thinking was to add a build menu item that will save
>> a Pundle as a parcel and load it and any pre-reqs into a base image.
>> This would be quite a nice alternative build mechanism.
>
>> Joerg
>
>> -----
>> Joerg Beekmann
>> DeepCove Labs
>> 4th floor 595 Howe Street
>> Vancouver, BC, V6C 2T5
>> voice +1.604.689.0322
>> fax   +1.604.689.0311
>> [hidden email]
>>
>
>> CONFIDENTIALITY NOTICE
>> Unless otherwise indicated this email contains information that is
>> private
>> and confidential. If you have received it in error, please notify the
>> sender
>> and delete this message along with any attachments.
>>> -----Original Message-----
>>> From: Michael Lucas-Smith [mailto:michael.lucas-
>>> [hidden email]]
>>> Sent: Monday, March 13, 2006 10:36 PM
>>> To: Charles A. Monteiro
>>> Cc: [hidden email]
>>> Subject: Re[2]: Parcel load times
>>>
>>> Yes it loads parcels just fine an' dandy. Actually with compression, I
>>> believe it'll be 1.5mb ish.. I can redo the experiment if you want and
>>> create scripts to make such an image.. are you interested?
>>>
>>> Cheers,
>>> Michael
>>>
>>> > Michael:
>>>
>>> > your wrote:
>>>
>>> >> Some other interesting facts: If you take the base.im or visual.im
>>> >> clean images and remove all the parcels, you end up with a 3mb
>> image -
>>> >> this isn't too bad, as under compression this is around 1.5mb + the
>> VM
>>> >> is 2mb-ish. That really -would- be an ideal executable size for a
>>> >> pluggable base application.
>>>
>>> > Do you actually have a base image i.e. a 3mb image which still can
>> load
>>> > parcels?
>>>
>>> > -Charles
>>>
>>> > On Mon, 6 Mar 2006 10:50:07 +1100, Michael Lucas-Smith
>>> > <[hidden email]> wrote:
>>>
>>> >> Hi all,
>>>
>>> >> There's been plenty of hot discussions about parcel's and their
>>> >> loading speed on this list before.. so I thought I'd throw in some
>>> >> hard data to help out.
>>>
>>> >> I've got a spreadsheet that shows the load time of 'base parcels' -
>>> >> parcels that either come with VisualWorks or that rarely change.
>>> >> http://www.spiritshigh.com/load-times.xls
>>>
>>> >> These parcels are included in the base image for SWS's XML
>>> >> WithStyle product. They add a hefty 5mb's of code to our base image
>>> >> (which compresses down to around 2.5mb when we make the .exe).
>>>
>>> >> "Patched" means that while loading the parcels, the following
>>> >> alteration is made to the parcel load logic:
>>>
>>> >> SystemUtils class>>modifySystem: aBlock
>>> >>             ^aBlock on: linkState do: [:ex | ex resume: false]
>>>
>>> >> This is undone at the end of the parcel loads and then 'SystemUtils
>>> >> linkSystem' is executed to ensure everything is linked up
>> correctly.
>>>
>>> >> "Unpatched" means the parcels were loaded as per Cincom intended
>> them,
>>> >> without any alterations to the system.
>>>
>>> >> On the second sheet there is a large graph showing the difference
>> in
>>> >> the load times, but the "Speedup" column on the data sheet shows
>> just
>>> >> how much of a difference the patch can sometimes make.
>>>
>>> >> Now, to really throw my spanner in to the works, I've shown the
>> totals
>>> >> down the bottom. Even with the patch, it takes 21 seconds to load
>> all
>>> >> these parcels. That's basically unacceptable for a desktop
>> application
>>> >> :/. I've also included the time to load all of the parcels that
>> have a
>>> >> reasonable speed up, excluding the ones that don't speed up. It
>> still
>>> >> takes 7 seconds - that's on the "barely acceptable" edge of load
>>> >> times.
>>>
>>> >> I should point out that this is the base code, so on top of this
>> the
>>> >> application code still has to load.
>>>
>>> >> The ultimate goal of the SRE and parcels, etc, was that a single
>> small
>>> >> base image could load up all the parcels in a reasonable amount of
>>> >> time. We're not there yet obviously.
>>>
>>> >> With or without the patch loaded, the profile of loading all of
>> these
>>> >> parcels is pretty consistent:
>>>
>>> >> 8.8% NameSpaceBindings>>lookup:
>>> >> 5.2% Object>>oneWayBecome:
>>> >> 3.8% Behavior>>bindingFor:
>>> >> 3.6% Behavior>>flushVMmethodCache
>>> >> 3.5% SequenceableCollection>>do:
>>> >> 3.0% GeneralNameSpace>>protectedBindingFor:modifiers:
>>> >> 2.8% Class>>protectedBindingFor:modifiers:
>>> >> 2.5% NameSpaceSearchRules>>forNames:do:
>>> >> 2.1% Set>>initialIndexFor:boundedBy:
>>> >> ... cut at 2.0%
>>>
>>> >> Basically, to be able to 'live the dream' and load all the parcels
>> in
>>> >> at startup (with as few exceptions as possible), I'd need the
>>> >> parcel load code to be at least 2-3 times faster than my patched
>>> >> loader.
>>>
>>> >> If that could be achieved, I'd package with the slowest loading
>>> >> parcels included in the base. This would then mean by executable
>> would
>>> >> be much smaller than it is now and 'online upgrades' wouldn't be as
>>> >> costly to my users bandwidth.
>>>
>>> >> Some other interesting facts: If you take the base.im or visual.im
>>> >> clean images and remove all the parcels, you end up with a 3mb
>> image -
>>> >> this isn't too bad, as under compression this is around 1.5mb + the
>> VM
>>> >> is 2mb-ish. That really -would- be an ideal executable size for a
>>> >> pluggable base application.
>>>
>>> >> Cheers,
>>> >> Michael
>>>
>>>
>>>

>
> BTW, these are the parcels I have loaded into my SRE:
>
> #( 'Arbor GIF Reader Writer'  'NakedWindows' 'TransparentWindows'  
> 'BOSS'  'BraceConstructor' 'NetClients' 'SMTP' 'POP3' 'FTP' 'HTTPS'
> 'SSL' 'X509'  'ASN1' 'AT MetaNumerics' 'ASN1-Support' 'DH' 'DSA' 'RSA'
> 'DES' 'ARC4'  'MD5' 'HTTP' 'Compression-ZLib' 'IMAP' 'Mail' 'MIME'
> 'NetConfigTool'  'NetClientBase' 'Blowfish' 'CiphersBase' 'SHA'
> 'HashesBase' 'SecurityBase'  'LoggingTool' 'Tools-Settings-VW'
> 'Tools-Settings' 'Aragon All' 'DDEML'  'DLLCC' 'PackageCategories'
> 'NetNamespace' 'URISupport' 'XML-source' 'XML')
>
> my Windows SRE is 5,820 KB which is compressed and includes reshacking  
> into a single exe.
>
> -Charles

> Charles,
>
> You can save few 100 KBs of the image size if you unload the 'DLLCC',  
> 'PackageCategories' and 'XML-source'.  You don't usually need DLLCC and  
>   'XML-source' to be presented in the runtime.
>
> --Mark
>
>
>>  BTW, these are the parcels I have loaded into my SRE:
>>  #( 'Arbor GIF Reader Writer'  'NakedWindows' 'TransparentWindows'  
>> 'BOSS'  'BraceConstructor' 'NetClients' 'SMTP' 'POP3' 'FTP' 'HTTPS'  
>> 'SSL' 'X509'  'ASN1' 'AT MetaNumerics' 'ASN1-Support' 'DH' 'DSA' 'RSA'  
>> 'DES' 'ARC4'  'MD5' 'HTTP' 'Compression-ZLib' 'IMAP' 'Mail' 'MIME'  
>> 'NetConfigTool'  'NetClientBase' 'Blowfish' 'CiphersBase' 'SHA'  
>> 'HashesBase' 'SecurityBase'  'LoggingTool' 'Tools-Settings-VW'  
>> 'Tools-Settings' 'Aragon All' 'DDEML'  'DLLCC' 'PackageCategories'  
>> 'NetNamespace' 'URISupport' 'XML-source' 'XML')
>>  my Windows SRE is 5,820 KB which is compressed and includes  
>> reshacking  into a single exe.
>>  -Charles

>
>
>> well, I wanted a process that did not involve RTP or better said any
>> stripping just so that element was eliminated from consideration for any
>> runtime issues that arise. . Also I would think that a better base would
>> be an image that did not have Store loaded.
>
> The visual.im doesn't have Store loaded. The way I use the RTP it  
> doesn't do much stripping at all, so it's very safe.
>
>>> Then if you use the RuntimePackager with -ALL DEFAULT SETTINGS- except
>>> that I also use compacted compiled methods, you end up with a  
>>> runtime.im
>>> that is 7,500kb.
>
>> does this keep all of VW kernel? If the debugger is present i.e. not PDP
>> can one actually step through code and see at least decompiled code. I
>> guess I don't understand what "compacting" compiled code means besides
>> "compacting it" i.e. making it smaller.
>
> the compacting, as Alan pointed out in another post, doesn't do much but  
> remove some instance variables from compiled methods. I'll probably stop  
> using it now.
>
> The old debugger is present, but even that can be removed, it doesn't  
> give you much of a space saving to remove it though.
>
>> One of my requirements is the capability of making any runtime quickly
>> "debuggable"
>
>> Also I guess you are using the RuntimePackage deployment notifier?
>
> Yep.
>
>> My process allows me to use the stock VW notifier i.e not PDP or a
>> specific one I built more suitable for a customer runtime deployment.
>
>> Finally, if I understand it correctly via your script the resulting
>> executable size is about 4mb which includes compression i.e. the
>> compression of the image prior to reshacking it.
>
> That's right.
>
>> BTW, these are the parcels I have loaded into my SRE:
>
>> #( 'Arbor GIF Reader Writer'  'NakedWindows' 'TransparentWindows'  
>> 'BOSS'
>> 'BraceConstructor' 'NetClients' 'SMTP' 'POP3' 'FTP' 'HTTPS' 'SSL' 'X509'
>> 'ASN1' 'AT MetaNumerics' 'ASN1-Support' 'DH' 'DSA' 'RSA' 'DES' 'ARC4'
>> 'MD5' 'HTTP' 'Compression-ZLib' 'IMAP' 'Mail' 'MIME' 'NetConfigTool'
>> 'NetClientBase' 'Blowfish' 'CiphersBase' 'SHA' 'HashesBase'  
>> 'SecurityBase'
>> 'LoggingTool' 'Tools-Settings-VW' 'Tools-Settings' 'Aragon All' 'DDEML'
>> 'DLLCC' 'PackageCategories' 'NetNamespace' 'URISupport' 'XML-source'  
>> 'XML')
>
>> my Windows SRE is 5,820 KB which is compressed and includes reshacking
>> into a single exe.
>
> Interestingly enough, my XMLWS .exe is about that size too.. I have  
> roughly the same sorts of things loaded in to it, plus Pollock and some  
> other stuff.
>
> Cheers,
> Michael