branchrust_reboot/main/expand_perf_telemcancel
14 Commits over 0 Days - ∞cph!
Bugfix: handle similar-to-inf budget timespans
Tests: spawned on Craggy - no exceptions
Buildfix: remove non-existent call
Tests: none, trivial change
Clean: remove extra level of indentation
Tests: compiles
Update: InvokeProfiler now pushes executed_time and invokes_executed
Tests: compiles
Update(breaking-change): WorkQueueProfiler now also reports BudgetTime
- breaking as this doesn't match CSV template
Tests: none, compiles
Update: WorkQueueProfiler now sends an extra aggregate record for queues
We could aggregate it on the backend, but that would mean sending through potentially a hefty amount of empty records
Tests: compiles
Clean: add a couple TODOs for when I'll be going through old analytics code cleanup
Tests: none, trivial changes
Update: extracted PersistentObjectWorkQueue.TelemStats into WorkQueueTelemStats
- made ObjectWorkQueue populate it
- every queue now always logs it's budget time, even if it has no work to run (so that we can estimate budgetted/total time %)
Opens it up for use in custom queues as well, but I'll cross that bridge later
Tests: compiles
Bugfix: ensure Runtime profiler reports WorkQueue and Invokes from the same frame
- moved it's logic to be invoked via PostUpdateHook.OnLateUpdate, rather than slamming it directly into PostUpdatehook internals
Previously invokes would be from last frame, while work queues would be from current. It's still a little wrong, as we're reporting it as data from last frame - but at least it's consistently wrong
Tests: none, will deal with any fallout later
Update: rejig a couple parts of TelemStats to simplify code
Tests: compiles
Update: PersistentObjectWorkQueue now gathers a bit more telemetry
- also fixes a potential bug with stale data uploading to our backend (another case in ObjectQueue)
There's a bug with it being desynced with the rest of the data (it's called last, but in reality is current), will fix later
Tests: none, not done yet
Update: runtime_profiler - track pre_lateupdate times
It's a category with a bunch of unity internal work that can take a non-trivial amount of time. Should make it easier to identify source of degradation.
Tests: dryrun of analytics in editor with runtime_profiling 1