1589977 - Review default profiler buffer sizes

Status: NEW

(Core :: Gecko Profiler, defect, P2)

Description

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Since bug 1576555, markers and their payloads are stored directly into the profiler buffer.
Previously they were kept outside in heap-allocated lists, with only a pointer getting stored in the profiler buffer during periodic sampling.

This means that the same buffer size may now capture a smaller time window, especially when recording fewer threads.
Bug 1585974 comment 3 has some details:

I did a small experiment, and recorded how the profiler buffer was used when recording just the main thread, and in real-life tests the new storage uses around 60% more than before, due to the extra marker data!
With default settings (main thread, compositor, dom workers) the extra use is around 23%.
And with lots of threads, it only takes a few percents more -- threads are heavy!

As seen in bug 1585974, we may record only a small part of some tests. The easy solution there was to bump up the profiler buffer size.

As a follow-up, we should have a look at other tests that use the profiler.
Also, maybe we should consider using higher defaults (in Gecko Profiler and/or in the popup.)

Comment 1

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Defaults (for MOZ_PROFILER_STARTUP_ENTRIES and popup) are being tweaked in bug 1632750. And after that the limit will apply to the whole Firefox app instead of per-process, therefore:

• Tests that force-set a too-small value may get worse!
• Using defaults should give roughly the same amount of data, but possibly more interesting data because now the oldest data across all processes is destroyed first, instead of blindly destroying old data in each process when reaching the (smaller) per-process limit.

So we may still want to review these defaults, but with new eyes after bug 1632750 lands.