NYCPHP Meetup

[Jim Hendricks(Biz Computing)]

Agreed that session variables aren't stored in memory between pages, but 
they are fully in memory for the life of every page while the session 
variable exists.  And as a session variable, the space would be consumed 
for each page currently being processed, so for 5 active connections, 
you would have 5 copies in memory.  I've seen discussion of a static 
memory area that can be used to simulate application scoped variables, 
but from what I've seen so far, that solution doesn't seem ready for 
primetime.  By storing the tree in a table, I eliminate the memory 
requirments, It would only be in memory when I need to display the tree 
& will build the display.  The table version of the tree would also be 
very simple since I don't need any linking information, just a key field 
to ensure the proper sortation, and depth indicator so I know how far to 
indent or what graphics to display etc.  

Lastly, from a memory standpoint, I have been burned too many times by 
knowing I work within a constrained environment but then design with 
false assumptions.  Here the assumption is that the memory for the class 
is not that much and that the total size of the tree will not be that 
great.  The first assumption could be answered by the php team, or 
someone else familure with the php memory model and therefore would no 
longer be an assumption.  The second assumption cannot be answered 
without putting a limit on the number of total items to be handled. 
 Putting a limit then creates the next assumption and that is choosing a 
limit everyone can live with for the life of the app ( with the 
assumption as to how long that life is ).  All these assumptions scare 
the crap out of me as a professional software developer because Mr. 
Murphy will screw me in the end.

Please don't take this as a flame, I think you have a great idea, just 
not an idea I think will fit in with what I am comfortable with.

Jim

Adam Fields wrote:

>On Wed, Oct 16, 2002 at 05:40:53PM -0400, Jim Hendricks wrote:
>  
>
>>The other reason for avoiding this is my Host Provider would croak if I 
>>build too much in memory thus hogging the memory shared across many 
>>sites.  I avoid as much memory use as I can so when I really need it 
>>it's available.
>>    
>>
>
>Seems reasonable. I don't know how much memory overhead the class
>implementation adds. I wouldn't think too much. Anyone?
>
>Even session variables aren't stored in memory though - they're
>written out to temp space on disk (at least, that's how I read the
>docs).
>
>  
>
>>Adam Fields wrote:
>>
>>    
>>
>>>On Wed, Oct 16, 2002 at 04:22:11PM -0400, Jim Hendricks wrote:
>>> 
>>>
>>>      
>>>
>>>>Adam Fields wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>I'd wrap a class around the whole thing. Use that class to broker
>>>>>reads and writes to the tree table. Add a "changed" timestamp to the
>>>>>tree, and have a read from the class only reload the tree from the
>>>>>database if it's changed since the last read. Stash the object in the
>>>>>session for reuse, or serialize it to another table (or file, or
>>>>>whatever) for quick retrieval.
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>I don't know about the class thing since it adds a level of complexity 
>>>>to the code that I don't know
>>>>if it's waranted.  
>>>>   
>>>>
>>>>        
>>>>
>>>I would argue that this will actually make the majority of your code
>>>simpler, because you're encapsulating the complexity. :)
>>>
>>>I'm the first to admit that classes aren't appropriate for everything,
>>>but they're the right approach for this kind of stuff.
>>>
>>>I'd do something like this:
>>>
>>>class tree {
>>>     var nodemap;
>>>     # and whatever else you want
>>>
>>>     function tree () {
>>>     # maybe some init code
>>>     }
>>>
>>>     function get_tree () {
>>>     # check if tree has changed or isn't populated yet
>>>     # if yes to either, get tree from db
>>>     # otherwise, maybe get tree from intermediate storage if you're
>>>     doing that
>>>
>>>     }
>>>
>>>     function save_tree () {
>>>     # write tree to db
>>>     }
>>>
>>>     function store_tree () {
>>>     # write tree to intermediate storage
>>>     }
>>>
>>>     function render_tree () {
>>>     # if tree isn't populated, get tree
>>>     # output tree html or tree values or whatever
>>>     }
>>>     
>>>     function get_tree_values () {
>>>     # return raw node data for the tree
>>>     }
>>>}
>>>
>>>Then, in your page:
>>>
>>>$mytree = new tree();
>>>$mytree->render_tree();
>>>or
>>>$mytree->get_tree_values();
>>>
>>> 
>>>
>>>      
>>>
>>>>I do like the idea of caching the tree though.  I 
>>>>would cache it in the DB so that the
>>>>tree does not need to be generated at all when the request to display it 
>>>>occurs.  The tree would
>>>>be regenerated everytime a change occurs to the underlying data ( which 
>>>>is a low volume data set )
>>>>This may not be a good idea for items that have a higher change velocity.
>>>>   
>>>>
>>>>        
>>>>
>>>While I wouldn't advocate this approach for something that changes
>>>once a minute or so, if it changes less than once an hour, this will
>>>probably still result in a performance gain, and it will be easier to
>>>maintain.
>>>
>>> 
>>>
>>>      
>>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20021016/92d12837/attachment.html>