The Inbox: Monticello-topa.585.mcz

> I’m late to the 4.5 wagon, I know.
> Probably this is not much but who knows:
>
> This was hinted by Stephan Eggermont.
> In one image that saved me 100k, but I think in images with much more
> versions loaded (seaside, magma, devel images) this could actually save a bunch.
>
> Best
>         -Tobias
> PS: ignore 584, i had my changes file corrupted.
>
>
> On 25.01.2014, at 21:08, [hidden email] wrote:
>
>> A new version of Monticello was added to project The Inbox:
>> http://source.squeak.org/inbox/Monticello-topa.585.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Monticello-topa.585
>> Author: topa
>> Time: 25 January 2014, 10:08:51.15 pm
>> UUID: ff122640-845a-402a-bd97-9fc79daea119
>> Ancestors: Monticello-cmm.583
>>
>> The number of distinct authors in the image is low:
>> (MCVersionInfo allInstances collect: [ :each | each author ]) asIdentitySet size. "13336"
>> (MCVersionInfo allInstances collect: [ :each | each author ]) asSet size. "128"
>>
>> Hence, we can safely store them as symbols.
>> This does not save much memory in a small image but should in
>> production images.
>>
>> =============== Diff against Monticello-cmm.583 ===============
>>
>> Item was changed:
>>  ----- Method: MCVersionInfo>>asDictionary (in category 'converting') -----
>>  asDictionary
>>       ^ Dictionary new
>>               at: #name put: name;
>>               at: #id put: id asString;
>>               at: #message put: message;
>>               at: #date put: date;
>>               at: #time put: time;
>> +             at: #author put: self author;
>> -             at: #author put: author;
>>               at: #ancestors put: (self ancestors collect: [:a | a asDictionary]);
>>               yourself!
>>
>> Item was changed:
>>  ----- Method: MCVersionInfo>>author (in category 'pillaging') -----
>>  author
>> +     ^ author asString!
>> -     ^ author!
>>
>> Item was changed:
>>  ----- Method: MCVersionInfo>>initializeWithName:id:message:date:time:author:ancestors:stepChildren: (in category 'initialize-release') -----
>>  initializeWithName: vName id: aUUID message: aString date: aDate time: aTime author: initials ancestors: aCollection stepChildren: stepCollection
>>       name := vName asString asMCVersionName.
>>       id := aUUID.
>>       message := aString.
>>       date := aDate.
>>       time := aTime.
>> +     author := initials ifNotNil: [:str | str asSymbol].
>> -     author := initials.
>>       ancestors :=  aCollection.
>>       stepChildren := stepCollection!
>>
>> Item was changed:
>>  ----- Method: MCVersionInfo>>summaryHeader (in category 'accessing') -----
>>  summaryHeader
>>       ^ String streamContents:
>>               [:s |
>>               s
>>                       nextPutAll: 'Name: '; nextPutAll: self name; cr.
>>               date ifNotNil:
>>                       [s
>> +                             nextPutAll: 'Author: '; nextPutAll: self author; cr;
>> -                             nextPutAll: 'Author: '; nextPutAll: author; cr;
>>                               nextPutAll: 'Time: '; nextPutAll:  date asString, ', ', time asString; cr].
>>               id ifNotNil:
>>                       [s nextPutAll: 'UUID: '; nextPutAll: id asString; cr].
>>               s
>>                       nextPutAll: 'Ancestors: '; nextPutAll: self ancestorString.
>>               self stepChildren isEmpty ifFalse:
>>                       [s cr; nextPutAll: 'Backported From: '; nextPutAll: self stepChildrenString].
>>               ]!
>>
>> Item was added:
>> + (PackageInfo named: 'Monticello') postscript: '(MCVersionInfo allInstances select: [ :ea | (ea instVarNamed: ''author'') isSymbol not ])
>> + do: [ :ea | ea instVarNamed: ''author'' put: (ea instVarNamed: ''author'') asSymbol]
>> + '!
>>
>>
>
>
>
>

>
> On 26.01.2014, at 18:00, Chris Muller <[hidden email]> wrote:
>
>> Symbols are one way to canonicalize Strings.  Another way is to
>> introduce one's own canoncalized IdentityDictionary of author strings.
>>
>> Whenever a Symbol is not going to be a selector name, I tend to prefer
>> the latter.
>
> Why?
>
>
>

> I ask you not to put this into trunk.  I actually have recent
> experience with this exact issue.  Let me explain.
>
> So, Monticello is not the only application to have lots and lots of
> redundant String instances.  MANY applications have that.  And MC also
> has lots of redundant Date instances (one per VersionInfo), as do many
> other apps.  And sometimes lots of redundant Float instances (i.e.,
> 0.0, 1.0, and 100.0 often will have lots of instances).  So slamming
> application-specific Strings into the SymbolTable does not solve the
> overarching problem while at the same time raising several new
> (non-obvious) issues of its own.
>
> One issue relates whether the app will ever want to scale into a
> database.  When an object is retrieved from a database, that object is
> associated with a particular DB Session, by identity.  But persistent
> Symbol objects, by their nature, cannot be associated to only one
> Session, because there can only be one in the image.
>
> The Monticello application is _already_ scaled into a database, Magma.
>
> Each of my own application instances has its own SharedObjects
> container.  It's just a simple wrapper of some IdentityDictionary's,
> one for Dates, one for literals (incl. Strings).  This way, each
> object belongs in its own persistent domain, and remaining a String to
> avoid being forced to be shared across persistent domains.
>
> We should not let any one app bloat the SymbolTable (which can slow
> down the system for ALL apps) merely for this purpose.  If we want to
> address this data redundancy, we should do so explicitly in the app
> (MC).  This is a recurring issue we should address it with a reusable
> first-class SharedObjectsContainer (or something else acceptable).
>
> Thanks.

> On Sun, Jan 26, 2014 at 11:06 AM, Tobias Pape <[hidden email]> wrote:
>>
>> On 26.01.2014, at 18:00, Chris Muller <[hidden email]> wrote:
>>
>>> Symbols are one way to canonicalize Strings.  Another way is to
>>> introduce one's own canoncalized IdentityDictionary of author strings.
>>>
>>> Whenever a Symbol is not going to be a selector name, I tend to prefer
>>> the latter.
>>
>> Why?
>>
>>
>>
>

>Each of my own application instances has its own SharedObjects
>container.  It's just a simple wrapper of some IdentityDictionary's,
>one for Dates, one for literals (incl. Strings).  This way, each
>object belongs in its own persistent domain, and remaining a String to
>avoid being forced to be shared across persistent domains.
>
>We should not let any one app bloat the SymbolTable (which can slow
>down the system for ALL apps) merely for this purpose.  If we want to
>address this data redundancy, we should do so explicitly in the app
>(MC).  This is a recurring issue we should address it with a reusable
>first-class SharedObjectsContainer (or something else acceptable).

>
> On 27.01.2014, at 12:06, Stephan Eggermont <[hidden email]> wrote:
>
>> Chris wrote:
>>> Each of my own application instances has its own SharedObjects
>>> container.  It's just a simple wrapper of some IdentityDictionary's,
>>> one for Dates, one for literals (incl. Strings).  This way, each
>>> object belongs in its own persistent domain, and remaining a String to
>>> avoid being forced to be shared across persistent domains.
>>>
>>> We should not let any one app bloat the SymbolTable (which can slow
>>> down the system for ALL apps) merely for this purpose.  If we want to
>>> address this data redundancy, we should do so explicitly in the app
>>> (MC).  This is a recurring issue we should address it with a reusable
>>> first-class SharedObjectsContainer (or something else acceptable).
>>
>> Ha, that’s the kind of comments I was hoping for. Thanks Tobias for
>> pushing this. An application specific value object cache makes sense.
>>
>> Stephan
>>
>>
>
> May we schedule this for 4.6?

>
> On 27.01.2014, at 14:17, Frank Shearar <[hidden email]> wrote:
>
>> On 27 January 2014 11:27, Tobias Pape <[hidden email]> wrote:
>>>
>>> On 27.01.2014, at 12:06, Stephan Eggermont <[hidden email]> wrote:
>>>
>>>> Chris wrote:
>>>>> Each of my own application instances has its own SharedObjects
>>>>> container.  It's just a simple wrapper of some IdentityDictionary's,
>>>>> one for Dates, one for literals (incl. Strings).  This way, each
>>>>> object belongs in its own persistent domain, and remaining a String to
>>>>> avoid being forced to be shared across persistent domains.
>>>>>
>>>>> We should not let any one app bloat the SymbolTable (which can slow
>>>>> down the system for ALL apps) merely for this purpose.  If we want to
>>>>> address this data redundancy, we should do so explicitly in the app
>>>>> (MC).  This is a recurring issue we should address it with a reusable
>>>>> first-class SharedObjectsContainer (or something else acceptable).
>>>>
>>>> Ha, that’s the kind of comments I was hoping for. Thanks Tobias for
>>>> pushing this. An application specific value object cache makes sense.
>>>>
>>>> Stephan
>>>>
>>>>
>>>
>>> May we schedule this for 4.6?
>>
>> Sounds like a good idea. Would you mind updating
>> http://wiki.squeak.org/squeak/6192 accordingly?
>
> Can I?