by over 50 times.
Looking at the usage, toHTTPDateStream is not called anywhere (except
internally by toHTTPDateString), and toHTTPDateString is called only
once outside of lldate.cpp, by LLStringUtil::formatDatetime. Also, the
method is most commonly called with a single two-character token, such
as "%Y" or "%A".
I therefore removed toHTTPDateStream and optimized toHTTPDateString.
Setting the locale was the most expensive operation, so I looked into
caching that, both in terms of std::ostream and strftime. The timings
for those implementations (averaged over 10 calls) is:
toHTTPDateString timings:
- with ostream (current) -> 0.314156 ms
- with ostream and std::locale caching -> 0.033999 ms
- with strftime and setlocale() caching -> 0.005985 ms
I therefore went with the standard C library strftime solution.
I also wrote a few unit tests to make sure that I didn't break any
existing functionality, and tested this under Windows and Linux.
Reviewed by steve.
Now using RunBuildTest.cmake to run tut and lscript_lsl tests, inorder to set path to llcommon.dll
Exported a few llcommon apis needed by server components/tests.
Ok, finally got this to a point where it doesn't break the build and I can check
in. llcommon can be built as a shared library (disabled but can be enabled with
cmake cache var LLCOMMON_LINK_SHARED.
reviewed by Mani on tuesday (I still need to get his suggested changes
re-reviewed)
(1) the LLLand class had to be forward declared in a cpp file that did not include llland.h
(2) ensure_equals(const char*, type, type) requires that type have an operator!=(type, type) defined.
(3) ensure_equals(const char*, type, type) is so overloaded that the compiler can have trouble picking the right version when it has to implicitly cast a std::string to "const char*" AND multiple valid casts exist for type --> S32, F32, etc. To solve this problem we must explicitly pass in a "const char*" instead of a std::string.
Reviewed with CG
Nat Goodspeed