grouper-dev - Re: [grouper-dev] Group Search Profiling
Subject: Grouper Developers Forum
List archive
- From: "blair christensen." <>
- To: "GW Brown, Information Systems and Computing" <>
- Cc: "Shilen Patel" <>,
- Subject: Re: [grouper-dev] Group Search Profiling
- Date: Tue, 7 Aug 2007 09:27:32 -0500
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=g8dkFaDA/BsVIW6ckQBDvdF0QPisIDLyJk7TFh6uBLCLfSbitzdGO8b3sJtJyFedvC/kPvXHgSKAQpn/nYH6WJGLmjbG6+QyRbsKNjnYwbM7ZTBMdYwMCRxszjhUM/XClANw/ZnzEsoqHjg2f8zHQKxH+6D1yhXklXbbBah+zw8=
On 7/31/07, GW Brown, Information Systems and Computing
<>
wrote:
> That's great. A quick look suggests that:
I agree. Thanks for passing along the snapshot.
> GrouperQuery.getGroups ->
> 11 seconds -> BaseQuery.filterByScope - stem filtering?
Yeah. I knew the scoping code was bad and in need of a rewrite. This
just reaffirms that.
> 7 seconds -> PrivilegeResolver.internal_canViewGroups
While I didn't set out to directly address this problem I have some
incomplete local patches that rework a lot of the privilege
resolution. While that isn't in HEAD yet I think it should help
reduce the number of generated queries.
> 5 seconds -> HibernateGroupDAO.findAllByApproximateAttribute
I'm surprised this part wasn't actually worse given how slow that method can
be.
> Collections.sort ->
> 11 seconds -> Group.getAttribute (492 invocations)
> This looks like a lot of repetitive checking of whether the attribute is
> valid for the group and retrieval of values. I expect a lot of this could
> be cut out by appropriate caching.
That seems excessive. I'll have to review that.
- Re: [grouper-dev] Group Search Profiling, blair christensen., 08/07/2007
Archive powered by MHonArc 2.6.16.