Much more than compilation. Functions come in two basic flavors, table valued & scalar valued. Scalar is used for a calculation, table valued are sort of like parameterized views. Only problem is, the scalar valued functions, when used in queries, can almost make the query go from a nice set based function to a RBAR (row-by-agonizing-row) function. And the table valued functions, when used in a single statement are usually fine, but when used with multi-statements, since they don't have statistics associated and the optimizer can't really generate plans for them, it assumes that the function is returning 1 (one) row and makes it's decisions from that fact. No big deal when returning a small number of rows, but a HUGE deal when returning larger numbers of rows.

Stored procedures are utterly different critters. I'd suggest hitting the Books Online & reading up on both to get more details. Then come back & read through the articles & posts to see the good uses functions can provide and the problems they can create.

Just as an example, we had a development team that saw how the functions worked and decided that they made the perfect sort of transition between object oriented code and database access. So they wrote queries that joined functions to functions and those functions called functions that joined between functions which called to ther functions,etc. It all appeared very elegant. Since all the execution plans were based on a single row of data, and the developers, while developing only ever used a single row of data for testing their code, everything worked fine. Then, after development & qa, we were getting ready for the production release and more extensive testing with production level data started. We got blocks, deadlocks, timeouts... It was a horrifying nightmare. We had to rewrite the entire data access layer into regular old SELECT statements inside stored procedures, not fun.

Be VERY careful about the use of functions.