On 9 January 2012 10:03, Peter Firmstone <[email protected]> wrote: > >> I think this is lacking context - what kind of service would one write >> that needs this many cores and thrashes that particular lock so hard >> it matters as compared to all the other compute it's doing? >> >> I'd also observe that running multiple processes gets you out of this >> predicament. >> >> In essence, I'm not sure it's a problem worth worrying about until >> it's a real-world problem worth worrying about. >> > > > I think I might just place a comment in the code with a possible solution if > it ever becomes a problem. You're right, the added complexity isn't worth > the hassle right now. >
Seems like the right choice to me. > The really odd part is, I've removed the policy caches, instead of slowing > down like I expected, the policies run faster, I've stripped the cache from > DynamicPolicyProvider too, making it far simpler, will commit soon. > Caches are not free exacting a price against the garbage collector, reducing memory for other operations plus CPU cycles just to maintain them. So like much else they bring a price and if that outweighs the benefits you'll see a speed-up when you remove them. I would be interested in understanding just how big that cache needs to be or how often it needs to be consulted for it to bring advantage. It could be it's only beneficial for e.g. App Servers that have ridiculous amounts of security load because of the way they're designed (and the associated assumptions). > I've fixed up MergedPolicyProvider and AggregatePolicyProvider also. > > Cheers, > > Peter. >
