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

v0.38 release plan #33

Closed
17 of 21 tasks
sergio-mena opened this issue Dec 23, 2022 · 2 comments
Closed
17 of 21 tasks

v0.38 release plan #33

sergio-mena opened this issue Dec 23, 2022 · 2 comments
Labels
release-plan A high-level tracking issue for a specific major release
Milestone

Comments

@sergio-mena
Copy link
Contributor

sergio-mena commented Dec 23, 2022

Was tendermint/tendermint#9428

The primary focus of the v0.38 release will be rolling out ABCI++ vote extensions and FinalizeBlock functionality.

Deprioritised from this release:

  • Operators should have more control over bandwidth consumption
    • Investigate where Tendermint bandwidth is being consumed (perhaps capture this in an RFC as an articulation of the problem space)
    • Find short-term wins/low-hanging fruit where bandwidth consumption can be reduced (ideally in Q4 of 2022)
  • Monitoring/logging improvements #54
@sergio-mena
Copy link
Contributor Author

Moved to Q3, as the final release is waiting on SDK v0.50.x's first RC

JimLarson added a commit to agoric-labs/cometbft that referenced this issue Sep 14, 2023
@adizere adizere modified the milestones: 2023-Q3, 2024-Q1 Jan 10, 2024
@melekes
Copy link
Contributor

melekes commented Jan 16, 2024

Closing since v0.38 is out.

Investigate where Tendermint bandwidth is being consumed (perhaps capture this in an RFC as an articulation of the problem space)

tracking issue: #30

@melekes melekes closed this as completed Jan 16, 2024
cometcrafter pushed a commit to graphprotocol/cometbft that referenced this issue May 1, 2024
…bft#2846… (cometbft#29) (cometbft#33)

* perf(libs/json): Lower heap overhead of JSON encoding (backport cometbft#2846) (cometbft#2876)

---

Many RPC methods require JSON marshalled responses. We saw this taking a
notable amount of heap allocation in query serving full nodes. This PR
removes some extra heap allocations that were being done. We avoided
using the more efficient encoder.Encode before, because it added a
newline. This PR changes the function signature for these private
methods to be using *bytes.Buffer, and then uses the in-buffer methods
(rather than a second copy). We then just truncate the final byte after
each such call, which does not waste any allocations.

I added a benchmark for the most complex test case.

OLD:
```
BenchmarkJsonMarshalStruct-12              78992             15542 ns/op            4487 B/op        191 allocs/op
```
New:
```
BenchmarkJsonMarshalStruct-12              93346             11132 ns/op            3245 B/op         58 allocs/op
```

Roughly a 3-4x reduction in the number of allocations, and 20% speedup.

- [x] Tests written/updated - Existing tests cover this
- [x] Changelog entry added in `.changelog` (we use
[unclog](https://github.com/informalsystems/unclog) to manage our
changelog)
- [x] Updated relevant documentation (`docs/` or `spec/`) and code
comments
- [x] Title follows the [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec
<hr>This is an automatic backport of pull request cometbft#2846 done by
[Mergify](https://mergify.com).

---------

Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com>
Co-authored-by: Andy Nogueira <me@andynogueira.dev>

* changelog

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com>
Co-authored-by: Andy Nogueira <me@andynogueira.dev>
(cherry picked from commit ee66963)

Co-authored-by: Adam Tucker <adam@osmosis.team>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-plan A high-level tracking issue for a specific major release
Projects
No open projects
Status: In Progress
Development

No branches or pull requests

5 participants
@thanethomson @melekes @adizere @sergio-mena and others