Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] main from bloomberg:main #1

Merged
merged 9 commits into from
Apr 25, 2022
Merged

[pull] main from bloomberg:main #1

merged 9 commits into from
Apr 25, 2022

Conversation

pull[bot]
Copy link

@pull pull bot commented Apr 25, 2022

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

pablogsal and others added 7 commits April 25, 2022 15:33
To make the README more eye-catchy, add an animated version of the live
mode at the top of the section about the live mode.
We missed removing this after some refactoring.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
These calls are no longer doing anything useful now that FileReader
calls `_populate_allocations` in its `__cinit__`. We missed removing
these calls after a previous refactoring made them no-ops.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Stop making the RecordReader hold a collection of previously seen
allocation records and memory records. Instead, have it store only the
most recently seen of each.

For now, we'll just save the records in the FileReader, but this
refactoring clears the way for us to do something more memory efficient.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
In exactly one place the `getHighWatermark` function went back to look
at a previously seen allocation, and only to get its size. Instead of
keeping a reference to the allocation and using that to look up its size
later, just save its size in the first place.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Previously we were requiring access to all allocations simultaneously.
This refactoring lays some ground work for us to be able to process
a capture file without holding all its allocations in memory
simultaneously.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Previously this was exposed as a separate property, rather than as part
of the metadata that all other header fields are exposed through.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
@pull pull bot added the ⤵️ pull label Apr 25, 2022
We are currently spending a lot of space in the result file in
non-native mode by writing the native frame id, which is always 0. To
improve the situation, specialize the native allocation record so the
regular one doesn't need to have this field.

Signed-off-by: Pablo Galindo <pablogsal@gmail.com>
We are currently wasting a lot of space by writing enumerations as full
blown integers, where we could force them to have only 1 byte as we are
not using values bigger than 255.

Signed-off-by: Pablo Galindo <pablogsal@gmail.com>
@pull pull bot merged commit aa0bead into Logistic98:main Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants