(per Monty code review)
The notion of storing LLMemoryInfo data both as an LLSD::Map and an
LLSD::Array of pair arrays arose from a (possibly misguided) desire to
continue producing stats output into the viewer log in the same order it
always used to be produced. There is no evidence that anyone cares about the
order of those stats in the log; there is no other use case for preserving
order. At Monty's recommendation, eliminate generating and storing the
array-of-pair-arrays form: directly store LLSD::Map.
(per Monty code review)
Explain why we intentionally don't suppress exceptions from boost::regex
objects constructed with string literals. Catch std::runtime_error from
boost::regex_search() and boost::regex_match(); log and return false.
On Mac, where LLMemoryInfo relies on a child process rather than any sort of
internal system API, try to produce more informative LL_WARNS output if
popen() fails to run vm_stat, or if vm_stat terminates with nonzero rc.
For postprocessing these stats, we'll want the time at which they were
captured. We'll want the current framerate too, but handle that at a higher
level.
So far we've only been querying GlobalMemoryStatusEx(), but
GetPerformanceInfo() delivers a bunch more memory-related stats that may be
pertinent. Try capturing those too. May not yet compile on Windows...
Recast stream() to display data from LLSD array rather than reinvoking OS
operations used to capture it.
Make refresh() cache LLSD data in map form as well as array; fetch items from
that in a few places to avoid going back to OS.
Previous code deliberately flowed the different lines from MEMINFO_FILE
together on a single line, which seems pointless to me, since we want to be
able to grep the viewer log to recognize individual stats.
Also replace classic-C LLFILE* machinery used to read MEMINFO_FILE with
std::ifstream and std::getline().
The trouble with remembering the slowest-ever framerate is that framerate
drops dramatically on login, then typically bounces back to something
reasonable during the session. So the session-normal framerate has to drop
pretty dramatically before it falls below the original login framerate. To
address this, only remember the last ~10 minutes of framerates, and log memory
stats every time a new framerate is slower than the previous 10 minutes.
Introduce FrameWatcher, a static object that hooks into the LLEventPump named
"mainloop" to get a call every frame. Track framerate over a defined sample
time (20 seconds atm); track minimum and log LLMemoryInfo every time we hit a
new minimum.
Add Mac logic to LLMemoryInfo::stream(): run vm_stat and log its output.
Add comments with Mac and Linux suggestions to
LLMemoryInfo::getAvailableMemoryKB(), responding to comment:
//do not know how to collect available memory info for other systems.
Modified Mac OS_VERSION string to include OS X version number in addition to Kernel version info.
DARWIN llcommon build now depends on Carbon in order to provide this functionality.
Reviewed by Richard.
But be more careful with CPU clock count on linux, so the fasttimer values are much more accurate than they were the last time we were with RDTSC, in absolute terms - back in the right order of magnitude anyway.
Also change many instances of Mhz to MHz.
Also some minor comment fixes.
Graham Madarasz