Most of the time is taken up by the import records operation, would be my guess, though any sort that reorders records on a summary field is likely to be slow.
Instead of importing records into this table, why not define a calculation field:
FieldA + FieldB + FieldC
and then define a summary field that computes the total of this calculation field?
If this works, you no longer need to import records into another table just to put together a summary report.
As it moves along, the scrip shows what it is doing. The delete and import appear to take seconds. The sorting goes on and on (27534 records remaining to sort, 26345 records remaing to sort, etc). You may be right, this is what it is saying to me.
Field A, B and C are text fields each holding a single text value from a drop down list of 35 choices (What is most important 1, 2 and 3.). I have created subsummary reports for field A and another for B and another for C. But then they wanted to see what it looked like with all three together. It would be 10,000 record from the parent times 3 = 30,000 values. I do not think A + B + C would get me that result. Tell me if I am wrong.
During the sorting process, your table of newly imported records are likely also indexing some fields and this will take a lot of time.
I have created subsummary reports for field A and another for B and another for C. But then they wanted to see what it looked like with all three together
I assumed from your last post that fields A, B and C were what were being totaled by a summary field. Now, I see this is not the case. I would guess from your posts that you have three fields and that a "category" type value is being entered into one or a combination of these fields and that the same value might be entered into any one of them. Is this the case?
If so, then I'd use a related table of up to 3 records in place of your fields A, B, and C. ( A portal or group of portals can be used in place of the individual fields on your current layout.) A summary report can then be set up for what you want from a layout based on this related table (calculation fields can pull data from the parent table so that summary fields can produce aggregate values such as totals, counts and averages) and no data import would be needed.