[Glass] Should I be worried about symbols lookup performance?

[Dale Henrichs via Glass]

Mariano,

I think the reason that we've disabled it by default is that we don't 
like to surprise legacy applications ... changing behavior is always 
dicey business ... ...a few of our customers have expressed a desire to 
be able to gc symbols so they are motivated to enable it ... the ones 
that haven't expressed an interest either don't care or are dependent 
upon the current behavior:)

I don't think that gc performance is specifically issue, although it 
does fall into the area where a legacy app may be sensitive to mfc times 
and will notice the change:)

You make a good point, so it might make sense to enable symbol gc by 
default for GsDevKit ... I submitted an Issue[1] for this ...

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/issues/72

On 04/01/2015 06:24 AM, Mariano Martinez Peck wrote:
>
>
> On Tue, Mar 31, 2015 at 7:11 PM, Mariano Martinez Peck 
> <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>
>     Hi guys,
>
>     I must admit I find strange to have Symbol GC disabled by default
>     (STN_SYMBOL_GC_ENABLED: false). Even more when the user guide
>     says: "If enabled, symbol garbage collection *is performed
>     automatically* in the background *and requires no management* "
>
>     In addition, in Pharo, SymbolTable is weak, therefore we assume it
>     will automatically be GCe.
>
>     So...is there any reason I am not seeing why this is disabled by
>     default?
>
>
> Ok. I guess the reason is:
>
> Most normal apps do not make lots of symbols. And most symbols of the 
> system are used by class names, selectors, categories, protocols, 
> etc.. And these do not change much (you almost never unload a 
> package).  And so...if the table is quite large.. then I would imagine 
> that in the "normal app" the GC might get slower for likely only 
> collecting a few symbols.
>
>
>     Thanks,
>
>
>
>
>     On Tue, Mar 31, 2015 at 3:12 PM, Mariano Martinez Peck
>     <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>
>
>
>         On Tue, Mar 31, 2015 at 3:08 PM, Dale Henrichs
>         <dale.henrichs at gemtalksystems.com
>         <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>
>             On 03/31/2015 10:57 AM, Mariano Martinez Peck wrote:
>>
>>
>>             On Tue, Mar 31, 2015 at 2:20 PM, Dale Henrichs via Glass
>>             <glass at lists.gemtalksystems.com
>>             <mailto:glass at lists.gemtalksystems.com>> wrote:
>>
>>
>>                 In 3.3 we will be providing a canonicalization
>>                 framework that would provide support for doing your
>>                 own conflict canonicalization at which time you would
>>                 switch to the StringkeyValueDictionary approach...
>>
>>
>>             That would be nice because I would like to take a similar
>>             approach with dates.... I have TONS of equal dates
>>             (spread in many different collections) that I would not
>>             care to manage them as #==  ...
>>
>>             BTW...I thought a regular Date would fit as immediate
>>             object but re-watching James video about immediate
>>             objects, it doesn't seem the case. Wouldn't it be
>>             interesting a SmallDate (if necessary) which would be
>>             immutable and immediate? may this be useful? most
>>             financial apps have tons of dates...
>>
>
>             Yes, SmallDate was one of the ideas that was thrown
>             around, but then the canonicalization framework approach
>             was chosen because it could handle a broader range of
>             classes, including Dates ...
>
>
>         Ok, yeah, that makes sense!  Uffff I am eager to read a blog
>         post written by you about the  canonicalization framework and
>         taking Dates as an example :)
>
>         Ok, very cool.
>
>         Thanks Dale.
>
>
>         -- 
>         Mariano
>         http://marianopeck.wordpress.com
>
>
>
>
>     -- 
>     Mariano
>     http://marianopeck.wordpress.com
>
>
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150401/4042b9dc/attachment-0001.html>