generally when you see this jump in execution time it has to do with a join being enforced by the addition of the formula (not the actual formula itself).
When you added this new formula did it include a field form a table that was 'dormant'?
You can sometimes see this in action by just dragging a field from the table into the report

Edited by DBlank - 31 May 2016 at 5:57am

I am not saying this is for sure what is happening in your report but it is frequently the issue when run times jump up. Crystal does not inherently enforce table joins. Just because the table was part of the report does not mean crystal is using it to create your data set. You have to either set the joins to enforced in the join or you have to use a field form the table in the report (in a formula counts as 'use'). Just because it is 'an existing table' does not mean it is part of your run time query. If your formula has a field from a table that had no other field used from it (including daisy chained tables) then the formula is 'enforcing' the join and changing your results.
The enforced join can make a result go from a few hundred rows to several million rows which also means doing calculations on all of those rows. If the table is not joined to other tables it can also cause a Cartesian result which can really make the row volume explode.
Like I recommended before, a quick and simple way to test this theory is to delete your formula and then (in preview mode) drag and drop each field used in the formula onto the report canvas (even just the report header) and see if one of these fields causes the report to 'slow down'.


Edited by DBlank - 01 Jun 2016 at 3:05am