Pre-compute the values as much as possible, put them in tables, and join to them. Using inline scalar functions makes the proc operate row-by-row, which is inherently slow. Joining to pre-computed values is inherently fast.

If the calculation is too complex for that, then move it out of the database into something that's more efficient at it, or move it to a CLR UDF, which will (if built correctly), be better at it than SQL is.

But it's very, very rare that building tables for these things can't get you the right results, and do it fast.

Let's take tax rates for example. Maybe sales tax.

You could build a function that would calculate sales tax based on state, county, city of merchant, and state, county, city of customer, and then use a function to look this up. Or you could build a table of state-to-state rates, including counties and cities, and then just join to that. Do you end up with a larger table to join to? Yep. Does your update code have to do more work when tax rates are changed or tax laws are modified? Yep. But the cost of those things is tiny compared to the fact that querying by joining to that table will be potentially thousands of times faster than an inline UDF. You have to build the table once. You have to update it every few years (in most cases). You might have to query it a few thousand times per hour. Put your speed on the query, in that case.