Thanks for looking at the file, and I'll try your suggestions.  I'm happy to upload a bundle file (assuming I can create one in this state) if that's what you need to more thoroughly diagnose the issue.  I thought "the project" meant the .cwp file.
 
I can be a control freak, but I'm confident that I didn't manually adjust 524288 markers.  Other than applying Melodyne, I didn't knowingly follow a different workflow than I've used in X2.  It sounds like you're describing a known issue, or at least an area with historical problems.  Is there a bug tracking number or link I could follow to help me avoid this situation in the future?

The bundle file suggestion was more to help you recover your project. If you can recall what AS operations you did that might help figure how your project got in that state. I doubt melodyne had anything to do with it.

Thanks to your help, I was able to recover the project.
 
The problem was in two copies of a single AudioSnapped clip.  Using audio transient view, I scrolled through the tracks looking for shifted transients.  When I got to one of the problem clips, the display become very slow to update.  Opening the AudioSnap palette took nearly a minute.  I could only see a half dozen or so white transients and a bunch of disabled markers.  The threshold was set to 75%, but the duration was over three times that of the project.
 
The clip is a measure of crescendo 32nd notes on a snare drum.  I believe I used AudioSnap's Quantize function to tighten them up, but that was weeks ago and I don't clearly remember.
 
I bounced one of the copies to a clip, deleted the originals, and replaced them with the bounced clip.  That has completely fixed the problem.  The .cwp file went from 60MB to 3MB.  Open and save times are back to normal.
 
Note that the .cwp file size was doubling every time I saved, even though I wasn't modifying the problem clips at all.  I could open the file at 60MB, delete some tracks with no AudioSnap, save, and the file jumped to 117MB.  So even if I did do something stupid with AudioSnap, something in SONAR was multiplying the markers (or at least the file size) all on its own.
 
I originally applied AudioSnap to that clip in X2, but I did not see a problem until the project was saved under X3.  It could be that the markers were multiplying every time I saved in X2, and it was a coincidence that I noticed the slowdown under X3.
 
Should I file a bug report before I delete the bloated .cwp files or clean the audio folder?
 
Thanks again for your help.
 
(FYI, there is no option to clear all snap markers that I could see.)

Glad you were able to recover the project. I'm pretty sure that the problem wasn't introduced in X3 but persisted from the old project. Please log a bug with the bad project (including the audio). You can zip up a folder containing the project and audio and send it. It would be good to know what is causing it to keep doubling in size and address that in the future.
I've seen some corrupted audio snapped projects before and the solution has been similar to what I asked you to do.
There isnt a clear aud snap markers which is why I recommended the bundle save which does that as a result of saving. In the future we may add that option to clear the markers.

Problem report is filed as CWBRN-20343.

Ah. I see the wheels are turning, albeit very slowly... 19 Months and 2 major releases of Sonar since I reported this problem and now someone has actually proposed doing something about it... instead of slagging me off for mentioning it.
Also, as I've mentioned here on the forum and in messages to Sonar Support, because Audiosnap on long and/or complex audio takes so much time to process there should absolutely be design feature (an "Are you sure?" dialog perhaps) to prevent audiosnap data being applied accidentally or unecessarily.  for the same reason, audiosnap should be available on a "per-clip" basis not "per track".  The amount of data created can be ridiculous and project files become unusable especially when the data is apparently multiplied by subsequent saves. I can't believe that two major releases of Sonar have come and gone without this major issue being fixed.
 
BTW If anyone with X2 or X3 has the time, I'd be interested to know if any of the functionality I listed in the post below is actually possible yet...
http://forum.cakewalk.com/Help-How-to-do-these-things-in-X1-m2577918.aspx  
forum.cakewalk.com/Help-How-to-do-these-things-in-X1-m2577918.aspx

The demo will be out soon enough.

A V Man
Ah. I see the wheels are turning, albeit very slowly... 19 Months and 2 major releases of Sonar since I reported this problem and now someone has actually proposed doing something about it... instead of slagging me off for mentioning it.
Also, as I've mentioned here on the forum and in messages to Sonar Support, because Audiosnap on long and/or complex audio takes so much time to process there should absolutely be design feature (an "Are you sure?" dialog perhaps) to prevent audiosnap data being applied accidentally or unecessarily.  for the same reason, audiosnap should be available on a "per-clip" basis not "per track".  The amount of data created can be ridiculous and project files become unusable especially when the data is apparently multiplied by subsequent saves. I can't believe that two major releases of Sonar have come and gone without this major issue being fixed.
 
BTW If anyone with X2 or X3 has the time, I'd be interested to know if any of the functionality I listed in the post below is actually possible yet...
http://forum.cakewalk.com/Help-How-to-do-these-things-in-X1-m2577918.aspx  
forum.cakewalk.com/Help-How-to-do-these-things-in-X1-m2577918.aspx

I think what might have happened is that to the best of my recollection, there just have not been a bunch of occurrences of this kind of issue (I am not taking any sides on this issue - just speculating on the apparently reduced attention given to it).
 
I am glad some improvement to dealing with this kind of corruption is available, and I hope you and the OP don't have this crop up again in any case.
 
Best of all to you guys, 
 
Bob Bone
 

Bob, I don't think it's the problem is technically data corruption (although it could be a precursor to data corruption - e.g. if you unplug/smash your machine in frustration). I think the problem is actually more prevalent that you think. Some people don't bother to mention the problems they encounter. Some might simply swap it for another product. Others may blame themselves, believing that the the problem is their own fault, caused by their specific set-up or just some freak on-off data corruption event. 
 
Alex, I was kind of hoping to get a reliable recent Sonar and running very soon, rather than wait for a demo to come out.  If you or anyone with X3C can give me an idea what to expect, especially in respect of whether these audiosnap inadequacies have been resolved and also if any of the features useful features listed at the top of my May 2012 post (which became the basis of a Feature request list to the bakery some days later) have been implemented...
 http://forum.cakewalk.com/Help-How-to-do-these-things-in-X1-m2577918.aspx

... any details would be greatly appreciated. The X3 web page worryingly offers no info in this respect.