Replace BlocksRingBuffer with ProfileChunkedBuffer
Categories
(Core :: Gecko Profiler, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: mozbugz, Assigned: mozbugz)
References
Details
Attachments
(8 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
After bug 1626837, ProfileChunkedBuffer
is complete and can now replace BlocksRingBuffer
.
Assignee | ||
Comment 1•5 years ago
|
||
Instead of a potentially-null pointer to a ProfileBufferEntryWriter
, we are
now providing a Maybe<ProfileBufferEntryWriter>
, which is safer.
Assignee | ||
Comment 2•5 years ago
|
||
Same as with BlocksRingBuffer
: Instead of a potentially-null pointer to a
ProfileBufferEntryWriter
, we are now providing a
Maybe<ProfileBufferEntryWriter>
, which is safer.
Depends on D71286
Assignee | ||
Comment 3•5 years ago
|
||
explicit operator bool()
and operator!()
were cute ways to make InChunkBuffer
quack like a pointer when testing if it's effectively null.
But after some experience, and since InChunkPointer
will not be used in generic code where pointers would be accepted, I now think that it's better to be clearer about it and use an explicit IsNull()
.
Depends on D71287
Assignee | ||
Comment 4•5 years ago
|
||
Renamed some variables to be more generic. Their type is going to change in the next patch, and that type doesn't need to be in the names; also it will make the next patch easier to review.
Depends on D71499
Assignee | ||
Comment 5•5 years ago
|
||
Depends on D71500
Assignee | ||
Comment 6•5 years ago
|
||
As opposed to ProfileBufferIndex
(no "Block"), ProfileBufferBlockIndex
is only supposed to point at a valid block start.
If we trust this assumption, it allows for quick access to the given block index inside the buffer, as we don't need to read blocks one by one until we reach the given position.
There are still safety checks (MOZ_ASSERTs in DEBUG builds) to verify that block indices are correctly used.
Depends on D71501
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
Renamed some variables to be more generic. Their type is going to change in the next patch, and that type doesn't need to be in the names; also it will make the next patch easier to review.
Depends on D71501
Assignee | ||
Comment 8•5 years ago
|
||
Depends on D71882
Comment 10•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/488d57eb1da7
https://hg.mozilla.org/mozilla-central/rev/79cc6c708645
https://hg.mozilla.org/mozilla-central/rev/ad1644ba541d
https://hg.mozilla.org/mozilla-central/rev/1c27b4d14959
https://hg.mozilla.org/mozilla-central/rev/d09fce7cef49
https://hg.mozilla.org/mozilla-central/rev/7f832cccb66e
https://hg.mozilla.org/mozilla-central/rev/c38f6467377d
https://hg.mozilla.org/mozilla-central/rev/1416b0415a5e
Description
•