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

Fri Apr 3 08:52:53 PDT 2015

On Wed, Apr 1, 2015 at 1:48 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>  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:)
>
>
OK. Maybe it would be nice to add something to avoid this. Imagine I know
in average I do not release much symbols, yet, I wan't to have the app down
(GC time) as less as possible.  So say I want to GC symbols only once a
week while I do run MFC daily.

Is there a way I can trigger the GC of symbols without having to do:

1) Stop stone
2) Modify system.conf to set STN_SYMBOL_GC_ENABLED=TRUE
3) Start stone
4) do all GC stuff... the markForCollection seems to be needed to done
TWICE to really free the symbols (this is explained in the docs)
5) STN_SYMBOL_GC_ENABLED=FALSE

?
 I don;t want to be changing configuration files.

Not urgent at all this ... since I CAN actually GC symbols everyday... I
just thought the it could be useful.

Ohhh...maybe in my code I can check whether I am on Sunday (or whatever)
and then via code set #StnSymbolGcEnabled to true??

> 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:)
>

Ok, good to know.

>
> 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 ...
>
>
Great, thanks!

> 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> 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
>
>
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150403/d80f1ca3/attachment.html>