6

I have heard that DateTime.Now is very expensive call (from here)

Is GETDATE() in SQL 2005/2008 expensive? Have I to cache it into a variable if my stored procedure uses it a number of times?

Community
  • 1
  • 1
abatishchev
  • 98,240
  • 88
  • 296
  • 433
  • 2
    Can you share with us where you heard "I have heard that DateTime.Now"? – Alfred Myers Sep 05 '09 at 12:49
  • Possibly from this recent question: http://stackoverflow.com/questions/1381370/hidden-boxing-in-the-bcl – adrianbanks Sep 05 '09 at 12:59
  • 2
    It's only expensive if you are calling it a lot. That question adrianbanks pointed out shows that it takes about 500 ms to call datetime.now 1 million times. Which is pretty slow, compared to something like incrementing an integer, or concatenating a couple strings (I tested it), but still isn't that slow. Unless you plan on calling datetime.now a couple million times in some time critical piece of code, it probably doesn't matter. – Kibbee Sep 05 '09 at 18:36

1 Answers1

6

It's not expensive: it comes straight from the OS.

I'd cache it anyway. It will most likely be different for separate calls if you have multiple statements. Say you have multiple inserts, surely you'd want the value to correlate acrosss tables?

If it's use in a SELECT, say, for output then it's only evaluated once usually.

gbn
  • 422,506
  • 82
  • 585
  • 676
  • 1
    Thanks. May I ask: for the usefuleness or for best speeling mistake today...? – gbn Sep 05 '09 at 12:42
  • (don't ever ask these kind of "OR" questions if you can't handle a plain "yes" as the answer) :-) – marc_s Sep 05 '09 at 12:52