Fix the event topic list inefficiency

[pepyakin]

With paritytech/substrate#2491 merged, we maintain a list of topics. Each item is paired with the block number in which the item was deposited. We did that to fix the issue when a block has identical contents for two blocks, the notifications won't be triggered for the second block.

However, this scheme is clumsy, redundant and inefficient, it just was the easiest way to leverage ::append. A better solution would be to put a block number only once instead for each item.

[pepyakin]

Another possible solution is to introduce another map similar to EventTopics and store some value there which is dependent on the current block (i.e. the simplest - the block number) for each topic, and make light clients to watch that as the primary way of fetching updates. A light client would load the list of event indexes for the topics only if the value in that extra map were changed.

However, this would require an extra write per used topic and would make a light client to deal with one additional layer of storage indirection.

[cheme]

regarding paritytech/substrate#2491, I wonder why a storage double map is used for EventTopics, wouldn't a simple map be fine?

[pepyakin]

I think I should’ve mentioned this in the docs: but this is the simplest way to make all storage locations to have the same prefix in tree. Thus it will allow us e.g. to use ‘kill_prefix’ there.

[cheme]

ok, I get it, I think we can optimize that by using kill_prefix over the internal prefix generated by the macro for a simple map (a new function may be needed)

[shawntabrizi]

@athei Can you look at this and figure a priority?

[athei]

The inefficiency I see here is one additional integer per event emitted. It doesn't contribute to storage bloat because this storage item is cleared in initialize. Also the process of emitting an event is dominated by the storage access. I wager that the single int does not contribute much.

I rate the priority pretty low.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.