call to bt_gatt_hids_init influences execution time of work queue

[ppryga-nordic]

Describe the bug
If an application registers gatt services for a first time the bt_gatt_init is called that at the end of the day leads to call to db_hash_store if CONFIG_BT_SETTINGS is enabled.
That also leads to block of system work queue for a long time if settings are stored in flash.

Expected behavior
Is that correct to store the hash every power up/reset of the application if the same services are registered once again?

Impact
It may cause decrease of a flash lifetime if device is restarted very often.
Can't run high frequency works in a system work queue because of lag provided by settins store of db hash.

[ppryga-nordic]

I apologize for wrong description of the issue yesterday. I've updated it to somethin (I hope) more meaning full.

[Vudentz]

I don't really get this one, the stack can only really tell if the services have changed by generating a hash and then proceed to compare to the stored one. As for calling db_hash_store doesn't setting_save_one actually checks if the value is the same and skip any IO, or that is not always the case, in which case we should probably compare to stored_hash before commiting anything.

[joerchan]

I don't really get this one, the stack can only really tell if the services have changed by generating a hash and then proceed to compare to the stored one. As for calling db_hash_store doesn't setting_save_one actually checks if the value is the same and skip any IO, or that is not always the case, in which case we should probably compare to stored_hash before commiting anything.

@Vudentz We had the same discussion here in a different issue and the conclusion there was that settings_save would not overwrite if the value was the same.
#20629 (comment)

[mfiumara]

This might be related to #22730

[joerchan]

This might be related to #22730.

That's probably correct. The hash will have to calculated, but should not be stored if not changed.

[ppryga-nordic]

@pdunaj or @MarekPieta can you verify if the issue still exist?

[mfiumara]

@ppryga this is probably resolved in #22730. Could you retest with lastest master and see if the issue is still there? You do have to ensure you add all your services before you call settings_load as documented in a9e0c6c.

[joerchan]

Close this as I was told by @MarekPieta that the issue has been fixed.