On Wed, Sep 28, 2011 at 17:28, Gabriel Charette <gcharet...@gmail.com> wrote: > Very nice! > > I really like where this is heading :)! > > I think it would be great to instrument this to know how many times we > need to use a PPH_RECORD_MREF, to avoid trashing the cache (i.e. > potentially there are specific cases where only a small field's value > changes and pickling the entire tree again is sub-optimal; if instead > we could detect those cases and simply output the required change > which could then be applied on the reader side it would potentially be > better... it is possible that we haven't been affected by these > specific cases up until now, but that they would all massively result > in PPH_RECORD_MREFs now (the instrumentation would also potentially > help us find some of those tricky mutation, if there are any caused by > other things than overloads, which we aren't aware of yet...just a > thought).
Yes, that's in the backburner, but I will wait until we have a more complete implementation to start looking into these optimizations. One thing that is very easy to do is to only try to handle mutations of shared trees (tree_node_can_be_shared). Those are the only trees we should even bother putting in the cache. Diego.
