Aggregation calc 'tipping point'

Question

I've observed an aggregation script anomaly that I'm hoping someone can shed some light on.
I have a test cube with a test dataset with the following aggregation script:
FIX("Scenario1","Scenario2","US Dollar", "Local Currency")
___Agg ("Product","Location","Cost Center");
ENDFIX
"US Dollar" and "Local Currency" are the only members in a (sparse) dimension named Currency. In this cube the aggregation calc runs in about 20 seconds.
Here is where it gets odd...
I also have to store FX rates somewhere in the cube and got the idea to include them as a separate section in the Currency dimension from this blog entry: http://glennschwartzbergs-essbase-blog.blogspot.com/2011/11/i-was-at-client-and-needed-to-do-some.html
So now my Currency dimension looks like this
Currency (Label Only)
___US Dollar (~)
___Local Currency (~)
___Exchange Rates (~) (Label Only)
_____FX Rate 1 (~)
_____FX Rate 2 (~)
_____FX Rate n (~)
I can add anywhere up to 21 FX Rates, and the above agg script always runs in about 20 seconds. Once I add the 22nd FX rate, the agg script jumps up to over 1 minute. I would expect no impact at all, considering the fix is on "US Dollar" and "Local Currency", but I've repeated the experiment multiple times and the result is always the same. My first thought was dimension order, since at 21 FX rates, I had the same number of stored members as the Scenario dimension, but flipping them in the outline makes no difference to the agg times at both 21 and 22 FX rates.
Does anyone have any ideas about what is causing this?

Answer 1

OK, I've peeled back a few more layers of the onion and found some answers and some new questions.
First, I ran several iterations of the test script while toggling the size of the data cache and didn't really move the needle much either way. As far as the data file cache goes, my understanding is that only matters when using Direct I/O and our environment is all Buffered I/O.
However I did have some luck with the Calc Cache.
By experimenting with the calc cache, I was able to get the script to run in the second cube, with the FX rate members, at roughly the same 20 odd seconds (down from over 60). I also set the message output to detailed and learned that the jump in performance is tied to the calc cache selecting a different sparse dimension for it's 'single bitmap'.
From log with original calc cache setting - took over 60 seconds:
Calculator Cache With Single Bitmap For: [Location]
From log with a lower calc cache setting - took about 21 seconds:
Calculator Cache With Single Bitmap For: [Company]
Note: The Company dimension is actually a 4th aggregated sparse dimension that I left out of my original post in an attempt to simplify.
Then I went back to the baseline cube (without the FX rate members) and toggled the cache settings similarly. In that cube it didn't seem to matter which dimension among these two was chosen as they both finish in about the same ~20 seconds.
So this leaves me with a couple questions:
1) Why is Essbase using a single bitmap when the cache should be large enough for multiple bitmaps and a single anchor?
2) Why is the performance better when it chooses Company rather than Location or Cost Center with a larger cache setting? The outline order for the 4 aggregating sparse dimensions is Product - Company - Location - Cost Center. I couldn't lower the cache enough to choose Product before it was so low the calculator cache gets disabled, and the calc blows out to over a minute again. And increasing the size beyond the Company 'sweet' spot to select Location or Cost Center also blows the calc out to over a minute again.
Thoughts?