[Seaside] Nuking objects when changing pages?

[Rick Flower]

Thanks David --

I know how to deal with this in a C++ environment -- I could just 
destroy the object and it's gone.. I'll have to admit that this is the 
first time I've done any real programming in an environment that uses 
nothing but GC mechanisms.. It's just a little different..

-- Rick

David Mitchell wrote:
> From a general Smalltalk perspective, I don't go helping the GC in the 
> normal course of things. I have tuned Smalltalk apps, but not Seaside.
>
> Just remove the pointer and let the GC clean up after me. Setting to 
> nil works for instance variables, remove the key in a dictionary, or 
> if it is a temporary, simply let it fall out of scope.
>
> If I had some evidence from a profiling session that showed it was 
> hurting, I'd consider it. I'd probably look at different GC settings 
> before I started adding tweaks to my app.
>
> Of course, I'd document the tune and make it easy to remove later 
> (perhaps by adding a method call). A tune here could be the bottleneck 
> there -- different VM, GC implementation, hardware, customer, etc.
>
> Rick Flower wrote:
>
>> Hi all.. I guess this is a question of style and garbage collection 
>> of sorts..  I've got a shopping cart as I mentioned earlier in 
>> several other email threads -- my question is what to do with the 
>> cart contents (and the object itself) when the user changes to 
>> another page thereby discarding what was in the cart (this cart does 
>> not work like a cart at Amazon or whatever -- when you leave a 
>> specific order page the cart is to be discarded).. Anyway, initially 
>> I was thinking that I could just set my cart object to be "nil" and 
>> let the garbage collector do its task -- but I'm wondering if its 
>> worth my time to do a bit of manual cleanup to reduce the amount of 
>> work the GC has to do.. Is it worth it and are there any pitfalls 
>> from going down that path -- any alternatives that are better?
>>
>> Anyway -- I guess it's more of a general ST question as well..
>>
>> _______________________________________________
>> Seaside mailing list
>> Seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>