Subject: Grouper Developers Forum
- From: Tom Barton <>
- To: Shilen Patel <>
- Cc: Grouper Dev <>
- Subject: Re: [grouper-dev] Performance of Group Searches
- Date: Fri, 19 Oct 2007 08:20:52 -0500
Shilen Patel wrote:
Tom Barton wrote:
In my example, this was the biggest performance win because the "ECON" stems were several stems down from the root stem. As long as the group name (or some other attribute of the group that's available) is named like it is now with the location, this should not constrain options to move and copy stems and groups. However, every group and stem name from the source hierarchy would have to be updated, but maybe that's okay given the kind of operation taking place?
I suppose so.
I can't think of a downside to pre-fetching group attributes.
Beyond the space they take up, compared to a list of UUIDs. So this is a clear space/time trade-off. Could you arrange to observe jvm memory usage with a search that nets an even larger number of groups, try to get a sense of how much of a trade-off?
It seems that member caching is clearly a Good Thing, that trying to push privilege checking down into the SQL layer breaks the model of independent privilege-checking (we want to eat our own dog food, after all), and that we can live with using names to determine relative location. All that remains is a little look over our shoulders at the size of the space/time trade-off.
- Performance of Group Searches, Shilen Patel, 10/18/2007
- Re: [grouper-dev] Performance of Group Searches, Tom Barton, 10/18/2007
- Re: [grouper-dev] Performance of Group Searches, GW Brown, Information Systems and Computing, 10/19/2007
Archive powered by MHonArc 2.6.16.