Cache properties that never change

[dwalton76]

We should cache properties that can never change...things like a motor's max_speed, counts_per_rot, etc

• ev3dev: cache invariant values for motors ev3go/ev3dev#53
• ev3dev: cache invariant values for sensors ev3go/ev3dev#54
• ev3dev: cache invariant values for ports ev3go/ev3dev#55

[WasabiFan]

I recall discussing this in detail previously... Did we really never implement it? Was there a PR somewhere which was closed? Or did we decide to cut it and save the related decisions for later?

[dwalton76]

Not that I remember but it may have been before my time

[WasabiFan]

I could've sworn I was discussing it on a PR with @ddemidov within the last month or two... I can't remember if it was part of said PR and we removed it, or if we were just including snippets in comments.

[ddemidov]

I could've sworn I was discussing it on a PR with @ddemidov within the last month or two...

This does not sound like anything to me :).

But caching the attributes on motor construction makes sense.

[WasabiFan]

Am I going crazy? I'm convinced we discussed this recently. We had a cache object, and if the property value existed in the cache it was used otherwise it was added to the cache... And we ran into some sort of decision to be made but didn't want to block the larger PR so we removed it.

Maybe I am insane.

[ddemidov]

May be I am just forgetting things :). Now that you mentioned it, I do remember some discussion involving python dictionaries, but I still can not remember when/where was that.

[ddemidov]

Was it about this function (#329, #330)? https://github.com/rhempel/ev3dev-lang-python/blob/06ae05faf27fc5d33dc5d26742a11ed2bc82e937/ev3dev/core.py#L1664-L1674

[WasabiFan]

Ooh, that looks like it! I guess we implemented a specialized version of this but not the generic solution.

[kortschak]

I'm considering the design for ev3go now and I'd like input from you all. The approach that I'm leaning towards capturing all the invariant attributes on opening the device (I'll add struct fields to the device types). This differs from the approach above in that there is an upfront cost to getting the values, but it means that I can make the methods to return the values later non-errorable. It also simplifies the handling of memoisation in that I don't need to retain and validity state marker.

Opinions?

[WasabiFan]

The fact that errors are entirely avoided by your approach is interesting; aside from that, I see very little reason to go one way or the other. And honestly, I don't think there's a significant difference from a speed perspective either, because the read operations are extremely quick when considered relative to all the other things happening in one of these apps. Overall, it seems reasonable to me.