more info on what I had in mind, I was thinking that the majority of the CommitHooks work on the same principle: the commit hooks creates a NodeStateDiff implementation, then it applies the diff, next the new state is returned.
My initial try was to shortcut this mechanism but allowing a CommitHook to return directly a NodeStateDiff impl (and not apply it directly), next if you can come up with a delegating diff that can simply traverse the hierarchy once and apply the diff, the problem is solved. I almost had this going until I ran into some CommitHooks that deviate from this standard behavior (like the ValidatingHook for ex which needs a root validator) alex On Fri, Feb 22, 2013 at 10:20 AM, Alex Parvulescu <[email protected] > wrote: > good point. > > I managed to do that for the indexing part (IndexHookManager & > IndexHookManagerDiff). the diff is processed only once and then the changes > are delegated to each available impl. > I was thinking about applying the same principle to the entire commit hook > stack but I wasn't able to pull it off. > > alex > > > On Fri, Feb 22, 2013 at 8:50 AM, Tommaso Teofili <[email protected]>wrote: > >> Hi Jukka, >> >> On 22/feb/2013, at 08:44, Jukka Zitting wrote: >> >> > Hi, >> > >> > We currently have half a dozen different commit hooks looking at each >> > commit. This means that each content diff is traversed at least half a >> > dozen times before the commit can be completed. As Thomas noted, this >> > causes a lot of extra reads especially with larger commits. >> > >> > I'd like to try unifying our various hooks into extensions of one >> > super hook that traverses the content diff only once, calling out to >> > individual validators and sub-hooks where necessary, a bit like how >> > the ValidatingHook already operates. >> >> +1, that sounds like a simple and valuable performance improvement. >> >> Regards, >> Tommaso >> >> > >> > BR, >> > >> > Jukka Zitting >> >> >
