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

[Mariano Martinez Peck via Glass]

On Tue, Mar 31, 2015 at 7:11 PM, Mariano Martinez Peck <
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> wrote:
>
>>
>>
>> On Tue, Mar 31, 2015 at 3:08 PM, Dale Henrichs <
>> 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> 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/2b06dd6b/attachment.html>