[nycphp-talk] Building trees
Adam Fields
fields at surgam.net
Wed Oct 16 22:23:54 EDT 2002
On Wed, Oct 16, 2002 at 07:38:00PM -0400, Jim Hendricks wrote:
> 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.
Because there are no application scope variables or the like, I don't
think the decision of whether you do this with classes is mutually
exclusive with the above. You could wrap a class around it, and
serialize/deserialize the tree class to the database as easily as you
could (more easily, in fact, since PHP includes an object
serialization routine, if you wanted to go that route) with straight
db access. Anyway, I think we've beaten this one to death. Good luck!
> 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.
Nope. Just enjoying the discussion.
> 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.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
> --- Unsubscribe at http://nyphp.org/list ---
>
>
--
- Adam
-----
Adam Fields, Managing Partner, fields at surgam.net
Surgam, Inc. is a technology consulting firm with strong background in
delivering scalable and robust enterprise web and IT applications.
http://www.adamfields.com
More information about the talk
mailing list