Tabular model: First deployment to server takes 120 min to process, subsequent ProcessFull 15 min?

Question

I have noticed this several times now and I do not understand it.
I have a model with ~45 million rows in the largest table and the first time I deploy to the server and then execute a ProcessFull (via script) it takes over two hours to complete.
*Note when I deploy from BIDS I have it set as Processing Option: Do Not Process.  So it doesn't process until I explicitly call it.
However, the next day (or could be later same day) I kick off the same ProcessFull and it finishes in 15 minutes.
So it appears the FIRST time it is deployed (as in the model did not exist historically, prior to deployment there was no tabular database called "MyTestModel" on the server) it takes an extremely long time.
Subsequent ProcessFulls are very quick.
Why is that?  Has anyone else encountered that?
When I watch the progress of the process full script I see it finishes retrieving all the data in a relatively decent amount of time, for example the 45 million row table:
Finished processing the 'BigTableWith45MillionRows' table.
So I know it has completed all its data retrieval operations.
Then it moves onto:
Processing of the 'Model' cube has started.
Processing of the 'ACCOUNT' measure group has started.
and many more various measure groups
later I get:
Finished processing the 'ACCOUNT' measure group.
Finished processing the 'Model' cube.
It moves onto to it's "CALCULATE;" statements at that point with "CREATE MEMBER CURRENTCUBE.Measures".... and so forth.
It would be most helpful if I could see which ones it had started but not yet stopped (it appears to "Started processing the 'random' hierarcy" or calculated column, or whatever and then a few lines later it will say "Finished" but other
than looking through them all by hand and matching up every Started with Finished trying to find one with OUT a "Finished" I have no way of knowing which are still processing.
It would be helpful to know "item X takes 2 hours to finish processing"
It tends to take the longest amount of time in the processing hierarchy and calculated column phase.

Answer 1

The default events in profiler are fine. You will likely focus on Progress Report End. How are you running ProcessFull? An XMLA script or from right-clicking on the database or from right clicking on a table and selecting all tables?
http://artisconsulting.com/Blogs/GregGalloway
Right click on database, go to process, select process full and then script (single database not each table).
<
Processxmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <
Type>ProcessFull</Type>
  <
Object>
    <
DatabaseID>MyDatabaseName</DatabaseID>
  </
Object>
</
Process>
I finished a full process yesterday and captured the info.
The biggest for CPUTime (I noticed duration would be long but no CPU time, it seemed like it would flag things as having started but due to dependencies they just sat and waited?)
was my larger hierarchy: Progress Report End, for CPU time of 11925840ms or 3.3 hours.  Duration was 11927999ms.
After that was my 45 million row table at CPU time 715296 and duration of 860773 or 14 minutes.
It is interesting because a normal ProcessFull is ~15 minutes, so it seems that the hierarchy rebuild is what is "killing me" on these.
A variety of Object Created events had high durations but NULL CPU time, seems like those were dependant on earlier events maybe??
Regardless, my big hierarchy was the longest at the 3.3 hours.
It has 173,000 unique rows in the hierarchy (again like Account primary, secondary, though 6 or so levels deep, 1.2.3.4.5.6 etc...)