On 27 Jan 2010, at 23:32, Mark Diggory wrote: > On Wed, Jan 27, 2010 at 10:16 AM, Simon Brown <st...@cam.ac.uk> wrote: > >> I confess that the reason why we are having this discussion at all >> eludes me. It seems like a fairly obvious bug for the importer to >> prune the indexes so many times (the comment for pruneIndexes() even >> says "called from the public interfaces or at the end of a batch >> indexing process"), it has a demonstrably detrimental effect on the >> performance of the software, and the fix for it is not particularly >> complicated. Is there something I've missed? >> >> -- >> Simon Brown <st...@cam.ac.uk> - Cambridge University Computing >> Service >> +44 1223 3 34714 - New Museums Site, Pembroke Street, Cambridge CB2 >> 3QH > > We discuss it because we seek to maintain an appropriate separation of > concerns in our architecture. And because Graham usually challenges us > to look at aspects of that architecture that are important. What is > under discussion is not that performance can't be improved by your > patch, you've identified a very important issue in batch processing. > We are discussing architecturally if we want to alter the > Context/EventManager framework and expose calls to pruneIndex. We > want to be careful to avoid exposing too much of the internals of the > Browse system outside in the application architecture.
That's fine; as I said in my initial submission, I know that my patch isn't the best way of writing that code. I should have made pruneIndexes() package private rather than public, for one thing. It was done to get the patch out and under discussion quickly and in a way which would hopefully minimise the effect on the rest of the code base. Having dug through the code a little more in the meantime, it seems that the effect of pruneIndexes() is to remove from the browse indexes information about items which are expunged and/or withdrawn; in that light it might not be necessary to call it when items are added or changed at all, thus reducing the patch to a single-line change. If that's the case I'll happily withdraw mine in favour of the new one. :) > Excellent work on finding a means to improve DSpace performance. Thank you. -- Simon Brown <st...@cam.ac.uk> - Cambridge University Computing Service +44 1223 3 34714 - New Museums Site, Pembroke Street, Cambridge CB2 3QH ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
