Noob questions about Energia and driverlib performance on 5529LP

Hello 43oh!  This is my first post here, so hopefully I will not screw it up too badly.  I come from a background of x86 assembly,  lots of C/C++ on x86, and a couple of years with some 8-bit PIC16F877 uCs and a C compiler called CCS PCM (NOT to be confused with CCStudio!). 

I've been plowing through the mountains of documentation available for the msp430 family.  Wow!  I decided to get my toes wet with Energia & msp-gcc on my Debian workstation and a MSP-EXP430F5529LP target.  I've been through the Energia reference, the DriverLib user's guide, and looked at a few header files.   It didn't take too long to get a serial connection running with the PC, and a functional printf so I can glimpse some of my code's antics.  I've used mspdebug to peek around inside the 5529 while reading through the datasheet and family guide -- although I have yet to figure out how to set breakpoints and trace through C source (that is going to be possible with gcc and mspdebug, right?).  It's going to take a while for everything to sink in, but I'm finally starting to feel optimistic that I'll be able to do cool things on this platform.

So, here's my current situation... While I had a sketch successfully exchanging bi-directional data with my PC, I had no idea about the internal state of the MSP430F5529 itself.   I set out to gather data, but quickly became confused about the best approach...  I wondered how to set or get current DCO configuration from inside an Energia app, and then I wondered if I should be making calls directly into driverlib from a sketch.  I was going to experiment with it, but then I didn't see a driverlib API for determining the current PMM state.  I see PMM_setVCore and its accompanying Up/Down siblings, but there's no PMM_getVCore API.  So, I used mspdebug to peek the register directly... 

(mspdebug) md 0x120 2
    00120: 03 96

Okay, so VCORE is at level 3.  This is not a low power mode, and I should expect full performance -- right?  So, I hook up a scope to P2_5 and run this loop:

void loop()
{
    digitalWrite(P2_5, HIGH);  
    digitalWrite(P2_5, LOW);   
}

On the scope I see a 200 KHz square wave.  Gee, that seems low... let's see what happens when we tighten up that loop a bit...
 

void loop()
{
  for (;;){
    digitalWrite(P2_5, HIGH);  
    digitalWrite(P2_5, LOW);   
  }
}

Well, it improved... 216 KHz square wave.   That can't be right can it?  Let's call driverlib directly and see what happens...

void loop()
{
  for (;;){
   GPIO_setOutputHighOnPin( GPIO_PORT_P2, GPIO_PIN5);
   GPIO_setOutputLowOnPin( GPIO_PORT_P2, GPIO_PIN5);
  }
}

Improvement again... 280 KHz square wave this time, but with a core at 25 MHz I kinda expected a bit more.

I also noticed that there was some sporadic triggering of the scope happening, so I assumed there were some interrupts gobbling up clock ticks somewhere -- perhaps from something Energia is doing with the dog?  I added a noInterrupts() call, just prior to the loop, but the only thing that changed was that the scope's triggering seemed much more stable.  These tests were done in a fresh sketch with no serial comms or anything else added.

Perhaps somebody will be so kind as to whack me on the head with some clues...  I want to force a clock rate for my core, and somehow confirm the same without the use of a scope.  I will eventually work to push this device into the lowest possible power modes, but first I want to see what she can do. 

I guess something needs to be tweaked with the UCS and/or DCO at start up? Should this be done with direct assignments to registers, or calls into driverlib, or did I miss a compiler directive?

If I tinker with any of these in an attempt to boost MCLK, is it going to throw a wrench into Energia's gears or require recalibrations of peripherals?

Regardless of the clocks, is it generally considered a bad practice to make calls directly into driverlib from a sketch?  I assume it must be "less bad" than poking bits directly into registers.

Thanks for looking!