Status of Internal Timing Routines

[Myoldmopar]

Over the years, profiling and timing tools have gotten better and better. I think at this point, we can do a whole lot more with external tools than we can do with the built-in routines and bookkeeping held in DataTimings.cc.

I'd like to know if anyone feels super passionate about keeping these internal timing routines and such, or if we could remove them to trim off an unnecessary chunk of code. @amirroth @mbadams5

[jasondegraw]

I do think it is useful to have the overall run time that gets reported (EnergyPlus Run Time=00hr 00min 14.37sec), so I'd like that to stay. But it could be done in a more modern way (std::chrono?) and probably be a pretty short/minimalist replacement for epElapsedTime.

[Myoldmopar]

Oh, yeah, for sure. Nothing would change on the user-experience side. I'm just thinking we can ditch all these internal timing and profiling pieces. Anything related to overall runtime, etc., would be easily mapped to a more modern and likely simpler approach.

[jasondegraw]

I guess it depends on whether you want to do something other then use a double for Time_Start and Time_Finish? If not, rewrite epElapsedTime, boom, done, delete the rest. Using a time_point or something like that would probably be better at the cost of requiring rework of the code that prints out the time, but that wouldn't be too bad. Right?

[Myoldmopar]

Commenting here to bump this thread. If this internal manually implemented timing code can be removed it will clean up another chunk of our codebase. If someone feels extremely strongly that they can't seem to run timing tests using existing modern tools and requires us to manually sample our own functions, please speak up loudly.

[Myoldmopar]

OK, I pulled the runtime calculation function out into UtilityRoutines, and removed all the manual function time tracking stuff, in PR #9506 which should be merged soon so I can lock this discussion at that time.