-
Notifications
You must be signed in to change notification settings - Fork 35
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
Improve events heap allocations #27
Improve events heap allocations #27
Conversation
@@ -178,7 +191,7 @@ func (a Attribute) String() string { | |||
|
|||
// ToKVPair converts an Attribute object into a Tendermint key/value pair. | |||
func (a Attribute) ToKVPair() abci.EventAttribute { | |||
return abci.EventAttribute{Key: toBytes(a.Key), Value: toBytes(a.Value)} | |||
return abci.EventAttribute{Key: []byte(a.Key), Value: []byte(a.Value)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This had a signficant impact on performance!
However its still silly that we have to keep re-allocating heap space for the keys, when ~all the time, they are actually constants.
I think we should change the data-backend here to be using []byte
, at least until abci events use strings.
sdk.NewAttribute(types.AttributeKeySender, fromAddr.String()), | ||
sdk.NewAttribute(sdk.AttributeKeyAmount, amt.String()), | ||
)) | ||
ctx.EventManager().EmitEvent(sdk.NewEvent( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kind of annoying, but this also actually improved performance of the entire benchmark by a couple percent, and moreso the event sub-set of it. It avoids extra heap allocations on the argument, and then avoids a slice copy, instead you just append a stack element.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm is the extra EventTypeMessage
actually used anywhere? I assume that's a general event emitted on basically all transactions that have a sender. It definitely seems like it makes more sense to just have the more specific EventTypeTransfer
here, but are we sure no one is indexing / searching by the more general type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wait, you're not actually getting rid of it lol, just separating it into two EmitEvents. The diff got cut off lol.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah woops, I should've copied more of the diff in the comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
@@ -210,15 +223,9 @@ func (e Events) ToABCIEvents() []abci.Event { | |||
return res | |||
} | |||
|
|||
func toBytes(i interface{}) []byte { | |||
switch x := i.(type) { | |||
case []uint8: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this case is never actually used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, and it was bad to be casting to interface and then reflecting.
sdk.NewAttribute(types.AttributeKeySender, fromAddr.String()), | ||
sdk.NewAttribute(sdk.AttributeKeyAmount, amt.String()), | ||
)) | ||
ctx.EventManager().EmitEvent(sdk.NewEvent( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm is the extra EventTypeMessage
actually used anywhere? I assume that's a general event emitted on basically all transactions that have a sender. It definitely seems like it makes more sense to just have the more specific EventTypeTransfer
here, but are we sure no one is indexing / searching by the more general type?
sdk.NewAttribute(types.AttributeKeySender, fromAddr.String()), | ||
sdk.NewAttribute(sdk.AttributeKeyAmount, amt.String()), | ||
)) | ||
ctx.EventManager().EmitEvent(sdk.NewEvent( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wait, you're not actually getting rid of it lol, just separating it into two EmitEvents. The diff got cut off lol.
* Significantly lower number of heap allocations that should be required by events * Use EmitEvent instead of EmitEvents
* Significantly lower number of heap allocations that should be required by events * Use EmitEvent instead of EmitEvents
* Significantly lower number of heap allocations that should be required by events * Use EmitEvent instead of EmitEvents
* Significantly lower number of heap allocations that should be required by events * Use EmitEvent instead of EmitEvents
* Significantly lower number of heap allocations that should be required by events * Use EmitEvent instead of EmitEvents
Description
closes: #XXXX
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes