Fix author-inherent, update weight

[4meta5]

• reuse slot if it costs anything to get it from SlotBeacon follow up for Ensure slot number is strictly increasing #41

follow up

update weight as per #41 (comment) (MOON-1613)

[notlesh]

I understand that this is a fudge factor, but it seems extremely high. What's the rationale for them?

[4meta5]

It was 10 writes before and now it is 11 writes. The HighestSlotSeen added 1 more write.

I do not know why the fudge factor was 7 writes, it isn't benchmarked so the author (probably @JoshOrndorff ) was presumably being conservative (and just estimating all reads + writes + computation as 10 writes).

[JoshOrndorff]

Yeah, it was me that added that fudge factor, and it was exactly as Amar says. I just wanted something quick and safe that was better than 0.

[JoshOrndorff]

This is tricky because it calls the SlotBeacon which can have any implementation it wants. I think this problem has been solved in substrate land. It's the problem of weighing functionality that is abstracted behind a trait. How do they do it for all the pallets that depend on Currency?

[4meta5]

It's true I was assuming T::SlotBeacon::slot() was 1 read. I think this is what most implementations will be in practice.

This is tricky because it calls the SlotBeacon which can have any implementation it wants.

@girazoki told me it's best to return (ReturnValue, WeightConsumed) in that case for the trait that is getting the value. So we'd need to change the SlotBeacon trait to return this tuple and change the impl to return the weight consumed too.

[girazoki]

I am in the process of benchmarking this, I think I have almost everything set except for paritytech/cumulus#1187.

[4meta5]

Suggested change

	#[pallet::weight((3 * T::DbWeight::get().read + 11 * T::DbWeight::get().write, DispatchClass::Mandatory))]
	#[pallet::weight((10 * T::DbWeight::get().write, DispatchClass::Mandatory))]

I'll revert the weight change so the objective optimization can get in.