message.Encode optimization about bcache

[yogyrahmawan]

I think for entries , we can keep using map because :

1. Insertion on map would take O(1) and slice would take O(n)
2. Getting data on map would take O(1) and slice would take O(n)

So for performance, I think it would be good if we keep using map data structure instead ofslice

[iwanbk]

So for performance, I think it would be good if we keep using map data structure instead ofslice

Please note that this is more about encoding performance.

Insertion on map would take O(1) and slice would take O(n)

hmm..yes, insertion operation performance will affect.
do you have any data that map is faster than slice?

Getting data on map would take O(1) and slice would take O(n)

we can exclude this, there is no get operation on the message

[yogyrahmawan]

we can exclude this, there is no get operation on the message

Oh my bad

hmm..yes, insertion operation performance will affect.
do you have any data that map is faster than slice?

Since someone already did benchmark on map vs slice in this ref : https://shakedos.com/maps-vs-slices-vs-arrays, I revoked my statement. For insertion, slice is faster than map.

So I agree for changing from map to slice

[iwanbk]

did some profiling, with this scenario:

• 40 concurrent key set, with 4K of total keys
• sleep for 2 seconds
• 40 concurrent key get, with 4K of total keys
• repeat forever

max keys is 100K.

There is no sign of issue in message.Encode performance.
So, i think we don't need optimization on this thing, at least for now.

cpu.pdf
heap.pdf