Thursday, May 7, 2015

Table Variables very slow performance

Actually you are correct,

i need to avoid using UDF as they are a performance killer.

i was planning the process this way as the same functions is used in all other reports for various reasons, and i was thinking in a way like OOP, so i need to centralize my customization if needed to.

Currently if my client wants to change how payroll element is calculated i can update that in one single function, and that will automatically update the entire product reports and screens accordingly.

product has more then 1300 screens and reports, and doing a change is extremely time explosive.

i will replicate my functions involved in process now and will try them as stored procedures with temp tables instead.

i even has made a try to move to SQL 2014 to utilize memory compiled procedures, and memory tables. but it is very limited feature as many options are not possible with new compiled procs.

and wondering whether i should build a DLL using VB.NET in order to do some processing in memory instead of the tempdb utilization.

thanks a lot for your great hep , will post back my testing results.

No comments:

Post a Comment