Anyone noticed multi-threading performance issues with SysUtils.Now?

-
Anyone noticed multi-threading performance issues with SysUtils.Now?

Or the TimeStampToDateTime WinAPI call in TryEncodeTime?

I've experienced weird contention and performance issues with it that went away when switching to GetSystemTimeAsFileTime.

Comments

  1. Lars FosdalJanuary 25, 2013 at 12:06 AM

    I use Now a lot in a heavily threaded server, and can't say I've seen any such issues.

    ReplyDelete
  2. Alexey PetushkovJanuary 25, 2013 at 12:09 AM

    Which issues ? Didnt really see. To measure performance i prefer GetTickCount - its faster

    ReplyDelete
  3. Eric GrangeJanuary 25, 2013 at 12:19 AM

    Alexey Petushkov I was basically hitting an edge case, the Now where used to TimeStamp objects, so where happening thousandths of times per second from threads. Yet, they shouldn't have been anywhere near performance critical, but the TimeStampToDateTime ended up eating 90% of the cpu time. When using GetSystemTimeAsFileTime to generate the TDateTime, performance went up by a factor 10 (ie. the calls became negligible).

    I don't remember having encountered that before though, so I'm not sure what is really happening...

    ReplyDelete
  4. André MusscheJanuary 25, 2013 at 3:20 AM

    TimeStampToDateTime does not contain that extensive code (at least in D2010, which Delphi do you use?). Maybe some kind of CPU alignment/cacheline problem? Hyperthreading? I also saw some assembly floating point stuff and I had some weird effects with a bad graphics driver (floating point stack corruption) long time ago...

    ReplyDelete
  5. Lars FosdalJanuary 25, 2013 at 3:33 AM

    Is there a critical section involved?  Did you remember to use that allocate extra memory for your critical sections to ensure that they get around the CPU cache lock issue?

    ReplyDelete

Post a Comment