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

Drop some useless allocations #2136

Merged
merged 5 commits into from
Aug 20, 2021
Merged

Drop some useless allocations #2136

merged 5 commits into from
Aug 20, 2021

Conversation

roman-khimov
Copy link
Member

TXs ≈ 1000000
RPS ≈ 31678.809
RPC Errors ≈ 0 / 0.000%
TPS ≈ 31219.756
DefaultMSPerBlock = 1000

CPU ≈ 34.589%
Mem ≈ 528.872MB

😉

The key to single-node performance is allocations now (and a bit of locking of course).

It makes no sense and we're using Bytes() pretty often.
 * both 'to' and 'from' are either Null or Hash160, there is no other
   possibility for valid NEP-17. So returning util.Uint160{} in case of
   parsing error is wrong.
 * but this is what allowed burns/mints to work at the expense of error
   allocation inside of util.Uint160DecodeBytesBE()
 * Uint160 can technically fit into regular VM integer, so even though it'd be
   quite surprising to see it there, TryBytes() is more correct (and easier!)
   to use
 * same thing with `amount`, we have `TryInteger()` that easily covers all
   possible cases and does appropriate error checking inside
Functions are usually immediately replaced (and it's OK for them to be nil,
searching through an array with length of zero is fine), Notifications are
usually appended to (and are absolutely useless in verification contexts).
@roman-khimov roman-khimov added this to the v0.97.3 milestone Aug 20, 2021
Comment on lines -1050 to -1057
var to []byte
toValue := arr[1].Value()
// we don't have `to` set when we are burning tokens
if toValue != nil {
to, ok = toValue.([]byte)
if !ok {
return
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initial intention was to explicitly prohibit all other item types (loose type check). But I agree the amount of such events is negligible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lacking neo-project/neo#1879 we really can get just about anything here. Also:
https://github.com/neo-project/neo-modules/blob/ef59a0eb27fb23c49610c0362e1fe7d9d0ec7839/src/RpcNep17Tracker/RpcNep17Tracker.cs#L135-L138
IIRC GetSpan() will do the same and extract uint160 from integer if it's there.

@roman-khimov roman-khimov merged commit 37c92f5 into master Aug 20, 2021
@roman-khimov roman-khimov deleted the micro-reduce-allocs branch August 20, 2021 13:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants