2,751 Commits over 669 Days - 0.17cph!
Update: resave after unity 6 upgrade
Tests: ran benchmark
Merge: from player_benchmark_improvements
Clean: remove naked player bench from ClothingBenchmark
Superceded by PlayerModelBenchmark
Tests: none, trivial change
Bugfix: avoid NRE when no recorders are requested by a benchmark
Tests: ran ClothingBenchmark
Update: PlayerModelBenchmarkScene - record bone count of spamed player models
Tests: ran benchmark
Update: BenchmarkScene - add support for selecting which recorders to activate
- added Scripts and Physics recorders
- PlayerModelBenchmark uses only Rendering + Animation ones
Tests: ran benchmark with various category bitfields
Update: add "CPU Total Frame Time" recorder
Tests: ran baseline
Update: add mainthread-only Camera.Render recorder
Tests: ran baseline
Update: PlayerModelBenchmark - add baseline run (0 models)
- change bench naming convention
Tests: none, trivial changes
Clean: get rid of RecordSampleCount - it duplicates MaxNumberOfFrames
Tests: none, trivial change
Update: Allow benchmark to stop after enough samples accumulated
- converted PlayerModelBenchmarkScene to run till 1k sampels accumulated
- support accumulated sample wraparound (explains weird results I saw previously)
Tests: ran player benchmark
Update: Add PlayerModelBenchmarkScene.UseRandomAnims - spawns players with different model states
- add a run per lod level with anims (bringing total to 12)
In theory should break batching/reuse, but results are a bit too similar(editor overhead?)
Tests: ran the scene
Update: define player spawning via desired lod level rather than manually placing them
Code lifted from editor gives results that don't land on the LOD boundary, but it still fits in the lod level.
Tests: checked triangle counts for every lod level, it falls as expected for every stage
Bugfix: convert bench durations from 120frames to 1s
Seems to accumulate more data from ProfilingRecorders, but it's sample count doesn't follow linear extrapolation. Weird.
Tests: ran the bench scene
Update: rename Perf.PlayerModel scene into PlayerModelBenchmark
- Purged it of original setup, instead controlled by a script
New bench script spawns 100 nakeds at various LOD levels and measures rendering stats
Tests: ran benchmark scene
Update: format output by recoder's unit type
- updated recorder's idents to for easier parsing
- skip recorders that didn't accumulate any data
Tests: ran the scene in editor
Bugfix(editor): silence UIBlackoutOverlay.Get error when running benchmarks in editor
Tests: ran ClothingBenchmark in editor, no longer blasted by errors
Update: BenchmarkScene - add support to gather simple rendering and animation perf telemetry
- ClothingBenchmark uses it for normal standing pass
Tests: ran ClothingBenchmark, checked debug output
Merge: from jobs3_skip_preallocnetwrites
- Optim: Jobs 3 - move netwrite pooling to all threads
Tests: ran around craggy with Jobs 3
Optim: Jobs 3 - skip running PreallocNetWrites
On a busy server we can end up sending 1.5k entities in a frame, and it can cost us 0.7ms total on preallocation. With recent pool rewrite we should be able to allocate on demand.
Tests: On Craggy ran around/broke stuff/ziplined with Jobs 3
Merge: from buildcommand_allocs
- Optim: reduce alloc count from building Arg commands from 20+ to 2 on average
- Update: expanded StringView API,
Tests: unit tests and running a bunch of different console commands
Update: Codegen
Tests: builds
Merge: from main
Needs codegen
Optim: reimplement all Arg.Get* via GetStringView
Avoids allocations in the GetString fallback
Tests: unit tests
Update: add StringView-to-numeric extensions
Tests: ran unit tests
Clean(tests): get rid of redundant profiling code
Tests: builds
Optim: BuildCommand - remove another Substring alloc via StringView
Down to 3 allocs/0.34KB per call
Tests: ran a couple commands with and without args
Optim: ConsoleSystem.Index uses StringView internally to avoid allocations
Tests: booted into craggy, ran a couple commands (short and fully qualified)
Optim: Arg.Args is now a StringView[]
Most of the code uses GetString to lazy alloc a string. BuildCommand is now 4 allocs/0.4KB per call
Tests: unit tests, booted into craggy and set a couple variables, tested crosshair clientvars
Optim: Arg.FullString is now a StringView
- updated CodeGenerator to support StringView params
- ran codegen
Saves an allocation(once I’m done with conversion). Currently at 12 allocs/0.85KB per call
Tests: booted into cragy, tried echo and say commands
Update: add StringView.Trim(char) overload
- add unit tests
Tests: ran unit tests
Optim: add StringView.SplitQuotesStrings overload
- Refactored logic to work on StringViews internally
Only has 1 alloc(StringView[]). Using it is blocked on whether I'll be able to convert Arg.Args field to StringView[] or not
Tests: none
Update: add StringView.EndsWith(StringView)
- added trivial unit test
Tests: ran unit tests
Merge: from pool_mt
- Bugfix: implemented missing Pool.Reset and ResetMaxCounterUsage
Tests: booted into craggy couple times with Skip Domain Reload active - no NYI exceptions
Bugfix: Implement Pool.Reset and ResetMaxUsageCounter
Tests: booted into craggy and stopped a couple times with Skip Domain Reload active
Update: add StringView.Trim
- added unit test
Tests: ran unit test
Update: implemented StringView.Replace
- added unit tests
Tests: ran unit test
Optim: SplitQuotesStrings - use pooled list internally
- also gave it a small clean, as it was a bit horrendous looking code
Saves us 3 allocs - down to 6 allocs, 0.25KB per call
Tests: unit tests
Optim: SplitQuotesStrings - replace regex usage with hand-rolled processing
Saves us 24 allocs per call - now 9 allocs, 0.5KB per call. As a bonus, looks to be 3-5x times faster
Tests: ran unit tests
Update(tests): more failing edge cases
Tests: ran unit tests, old logic passes
Update(tests): add a couple more trimming edge cases
Discovered during rewrite
Tests: ran unit tests
▄█▉▍▆▋▆ ▌▆█▌ ▄▌▌▆▄▍▌▇▊▉▆▆▍▄▄▇▌█▄▅▌▌█▊▄▌▄▇▊▋ ▊▊▋▍▅▇▋ ▅▆▉▌ ▉▊▍▋▆▉▌▆ ▇█▇▅▇▍▅ ▇▅▆▅▌█▋▌▍▊ █▍▌▋▊▊▆ █▇▇ ▅▉▍ ▋▇▆ ▅▆▇▆▉█▄▄▍ ▉▍▄▋▇▌ ▌▄▄▌ ▊▍▉▋▋▄
█▆▌▊▌▌▌ ▇▅▅ ▅▆▅▇▉█▉▆▇▆▇▄▄▊ ▍█ █▆▆▆▋▊ ██▇▄▄▇▅▄▄▇▅ ▊█▇▍▊▄▄██ ▌█▋ █▅▆▋█▇▊▅▌ ▇▉▌▊▄▉▇ ▅▄▆▆▄▍█▅▊█ ▌▅▅▌▇▋▍▋▌▌▌ ▊▋▊█
█▊█▆▍▅▍▇ ▌▇▊ ▋▋▇▅▅▊▍▆█▅▉▋▍▋ ▅▋▍▊▊▄▅▊
